Sume image 400s name the valid values: retry in code

When a Sume image request fails validation, the 400 body tells you what would have worked. The error envelope is {"error": {"code", "message", "request_id", "next_action", "details"}}, and for value errors details carries the field name plus the accepted list or range: supported for enums, allowed for a fixed set of integers, min and max for ranges. A client can read those and retry once with a valid value instead of failing a whole batch.

Every row in the table below was produced by running the request normalizer on origin/main with a deliberately bad value, so the messages and details keys are real, not paraphrased. The envelope fields come from the API's error handler; check the live response if you rely on a field I did not list.

Seven errors and what each one tells you

Two codes show up. invalid_request means the value is wrong for this model, and details lists what is valid. unsupported_parameter means the model does not take that parameter at all, and details.catalog_url points at /v1/images/models so you can see what it does take (Sume Image API docs).

The practical rule is that only the first kind is worth an automatic retry. An unsupported parameter should be removed from the request or fixed by choosing another model, and that is a decision for the caller.

A one-retry repair function

The function below takes the request body and a parsed error envelope. For an enum field it swaps in the first supported value; for allowed it picks the nearest allowed integer; for a range it clamps. It returns a new body, or None when the error is not a value error it can fix. The demo at the bottom feeds it two of the real error shapes from the table.

Picking the first supported value is a deliberate placeholder. In production choose with intent: the nearest ratio, the cheapest quality, the largest allowed n. The point is the structure, because the data you need is already in the error.

def repair(body: dict, err: dict) -> dict | None:
    if err.get("code") != "invalid_request":
        return None
    d = err.get("details") or {}
    field = d.get("field")
    if not field or field not in body:
        return None
    fixed = dict(body)
    if "supported" in d:
        fixed[field] = d["supported"][0]
    elif "allowed" in d:
        fixed[field] = min(d["allowed"], key=lambda v: abs(v - body[field]))
    elif "min" in d and "max" in d:
        fixed[field] = max(d["min"], min(d["max"], body[field]))
    else:
        return None
    return fixed

print(repair({"n": 2}, {"code": "invalid_request", "details": {"field": "n", "allowed": [1, 4]}}))
print(repair({"n": 5}, {"code": "invalid_request", "details": {"field": "n", "min": 1, "max": 4}}))
print(repair({"quality": "very_low"}, {"code": "invalid_request",
      "details": {"field": "quality", "supported": ["low", "medium", "high"]}}))

Where not to auto-repair

Do not repair silently when the value change alters the price or the output. Moving Ideogram from very_low to low changes cost; reducing n from 5 to 4 changes how many images you get. Log the change, and for billed workloads keep the repair behind a flag. If you want the background on one error family, see GPT Image 2.5 unsupported_parameter 400.

Two codes should never be retried unchanged: streaming_not_supported (omit stream) and unknown-model 404 model_not_found. Both need a different request, not the same one again.