Still on /v1/image-router/generate? It works but gets no new params

POST /v1/image-router/generate and GET /v1/image-router/models still work on Sume, but they are deprecated and will not get new parameters; POST /v1/images is the replacement. New fields such as mask_url, background and the quality levels xhigh and max are documented on the new route.

What the docs say

The Image API page states that the legacy routes still work without change, that they are deprecated, and that this surface replaces them. It also says Sume accepts the bare Image Router ids, such as gpt-image-2 and nano-banana-2.1, as aliases for the org/slug equivalents, so an id change is not forced on you on the same day as the route change.

A safe migration order

Move in three steps, which keeps each change reviewable. First change only the path and keep your bare model ids, since the aliases still resolve. Second, move the ids to the org/slug form and read GET /v1/images/models instead of the old models route. Third, adopt the new parameters you care about, such as background: transparent for GPT Image 2.5.

Check responses after step one. The new route returns Sume-hosted URLs in data[].url and a usage.cost in USD, and a request longer than 30 seconds returns a 202 job envelope. If your client assumed the old shape for finished images, test that before you ship.

Parameters that are unsupported, not ignored

The new route rejects a parameter that the selected model does not list, with 400 unsupported_parameter. That is a change from a client that silently dropped unknown fields, so a field you have been sending without effect might start failing. In v1, output_compression, seed and explicit pixel size are in the schema, but no model advertises them, so they return the same error.

What to test

After the path change, run one request per model you use and compare usage.cost to the price you expect. Then run one request with an unsupported parameter to see the 400 unsupported_parameter in your logs, so your error handling is ready for it.

The legacy Image Router entry in the catalog still lists its own endpoints and model ids, so nothing breaks on the day you read this. The point of moving is to get new fields and the per-model descriptors.