Change the date on a wedding invitation image: one Ideogram 4.5 edit

To change the date on an invitation image, send the invitation as the first input_references entry on POST /v1/images and quote the old and new date lines. Pin ideogram/ideogram-v4.5, leave out aspect_ratio, and say that names, venue and artwork stay identical. This is one call per invitation design, not per guest.

Ideogram's launch post (read 2026-10-05) calls 4.5 "the most precise edit model" and says it is live in the API. A date is a good test of that claim: it is short, it sits near other text, and a wrong digit matters.

The request

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: invite-date-001" \
  -d '{
    "model": "ideogram/ideogram-v4.5",
    "quality": "medium",
    "prompt": "Change the date line from \"June 14, 2027\" to \"June 21, 2027\". Keep the names, time, venue, border and flowers identical.",
    "input_references": [
      {"type": "image_url", "image_url": {"url": "https://example.com/invite.png"}}
    ]
  }'

Script fonts and decorative type

Invitations often use script fonts with swashes, which are harder to redraw than plain type. If the date line is in a script face, say so: "keep the same script lettering style". Ask for the new digits to match the thickness and slant of the old ones. Run a draft first and zoom in on the digits, because a 1 and a 7 in a flourish can look alike.

If the model gets the digits right but the style slightly off, run it again at a higher quality tier. The docs list low, medium and high; medium is the default.

Some changes are better made in the source design. If you still have the layered file from your designer, change the text there. An image edit is for the case where you only have the finished image. Also avoid editing text that must be legally exact, such as a venue license number on a ticket. For an invitation to friends, a date edit is a fair use. Always have someone who did not run the edit read the result against the new details before it goes out.

Before and after checks

Read the new date aloud. Check the weekday if the invitation prints one: the model will not recalculate it, so state both in the prompt ("Saturday, June 21"). Check the time line, the RSVP date and any "save the date" text elsewhere on the card, since they may need to change too and the model only changes what you name.

If the date appears in two places, name both. If the invitation will be printed, run the final at quality: high and inspect it at print size.

Two small rules

• One request per change set. Do not ask for a date change and a new venue and a new font in one call unless you check all three.
• Keep the original file. If the edit is wrong, start again from the original rather than editing the edit.

Billing note

A completed edit is billed in full, even when the date is wrong; a failed or cancelled one is not, per the Image API docs. Check a low draft first, then run the final.

Think about the delivery as well. A printed invitation needs a high resolution file, and an edit result may be smaller than the print size you need. Sume lists 1K and 2K for resolution on this model, so check that the size suits your printer before you order anything. For a digital invite sent by message, either size is likely fine. Send yourself the final file on the device where guests will read it. Keep the scope of this advice in view. It rests on the Sume docs and the vendor pages named in the sources, read on 2026-10-05, and on nothing measured by Sume. Where a behavior depends on your own images, such as how a model redraws a certain typeface, run a small pilot at the low quality tier and judge the result yourself before you plan a batch. Write down the prompt, the model id and the quality tier you used, so the run can be repeated. When the catalog or the docs change, re-read them; the live catalog is the contract, and a post is only a snapshot of it.