Move an edit call from /v1/image-1.0/generate to POST /v1/images

To move an edit call off POST /v1/image-1.0/generate, switch to POST /v1/images, rename the reference field from image_urls to input_references, and set model. Sume's docs say it will retire Image 1.0 soon, that its URLs are compatibility aliases for the Auto pipe, and that new integrations should use POST /v1/images with model: "sume/auto" or a catalog id.

The field map

Each row comes from the two docs pages. Check the live catalog before you rely on a row for a pinned model.

A migration order that is safe

Move one call site at a time. First, list every place that calls the Image 1.0 URLs, including the model-run alias POST /v1/models/sume/image-1.0/runs, which the docs say takes the same body. Second, switch one site and compare responses: the status code logic changes, so test both a quick job (200) and a slow one (202). Third, once all sites are moved, delete the old field names from your code.

Because Image 1.0 uses Auto selection, the first move can keep model: "sume/auto" and change nothing else about the result. Pinning a family is a second, separate decision.

Fields that exist only in the old shape

The Image 1.0 docs say its legacy request shape includes avatar references and transparency. The Image API does not list them in the parameters table; the docs send transparent stills back to Image 1.0. If your edit call relies on either, plan to keep that call on the old URL until the docs say otherwise. Also remember the deprecated aliases input_urls, n and format: Image 1.0 still accepts them, but the docs ask you to use the current names.

Before and after

The Image 1.0 call from its docs:

POST /v1/image-1.0/generate
{"prompt": "Keep the product identical; swap the background to a soft daylight studio",
 "image_urls": ["https://example.com/product.png"],
 "quality": "medium", "aspect_ratio": "4:3"}

POST /v1/images
{"model": "sume/auto",
 "prompt": "Keep the product identical; swap the background to a soft daylight studio",
 "input_references": [{"type": "image_url", "image_url": {"url": "https://example.com/product.png"}}],
 "quality": "medium", "aspect_ratio": "4:3"}

What else changes

The response shape changes. Image 1.0 returns the job envelope with result.artifacts[]. The Image API returns 200 with data[].url when the work finishes inside its 30-second wait, and 202 with the job envelope when it does not. Handle both by status code, not by body shape; the docs say so in as many words.

Parameters a model does not list return 400 unsupported_parameter. Transparent stills still go through Image 1.0 with transparency: true, per the Image API docs, so keep that call until the catalog covers your case. Pin a model if you need the same behavior twice, because sume/auto never discloses which family ran.

Do not forget the test side of a move. Record one known edit request in the old shape and one in the new shape, keep both in your test suite, and assert on the pieces that changed: how the source images are passed, how results come back, and how a slow job is polled. Those three are where most migration bugs live. Remove the old test only once the old route is no longer called anywhere. 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.