Ideogram remove-background 200 with an error body vs Sume errors

Do not trust a 200 alone on Ideogram's synchronous remove-background call. Its page says that if a synchronous request fails after the response has started streaming, "the HTTP status is already 200; the body contains error and status_code". Check the body for those fields before treating the response as an image. On Sume, failures are read from the job's error metadata.

Ideogram facts are from its remove-background page; Sume facts from Errors and credits, both read 2026-10-01.

What does the Ideogram page say?

The endpoint is POST /v2/image/remove-background/ideogram-1, multipart, with a source image of JPEG, PNG or WebP up to 25MB. A successful synchronous call returns data; a failure after streaming began carries error (message) and status_code (the status it would have returned before streaming). With async you get a generation_id and poll instead.

Where does a failure live on Sume?

Failed jobs expose public error metadata such as category, stage, retryability, retry-after seconds, public reason, and next action. Internal provider payloads are not public API fields. The Sume tool for this task is rmbg_create.

How should my client handle both?

Treat success as "status OK and no error field", not "status OK". For Sume, read the job status and its error category, then follow the documented next action: for generation_rejected, inspect events and fix the input; for unreachable media, check the image is a public HTTPS URL. A Python walk-through is in remove background from an image in Python.