A Sume 400 that returns a job id: input rejected at provider submit

A Sume 400 normally means nothing was created. There is one exception: when the request passes admission but the generation input is refused at the moment Sume submits it, the response is still 400 invalid_request, yet error.details carries a request_id, a status_url and a job. A failed job exists, its hold is refunded, and the fix is to change the input and send it under a new Idempotency-Key.

Why does a 400 have a job id?

Paid generation reserves the balance and writes a job row before it calls the generation runtime. If the runtime layer then rejects the input shape, for example a missing image_url, audio_url or video_url for a mode that needs one, or an unsupported generation model, the API marks the job failed with the internal code invalid_provider_input, refunds the usage with the reason provider_submit_failed, and answers 400 with the specific message, such as Missing image_url.

The docs say the same in general terms: the reservation is taken when Sume accepts the request, and failed jobs release or refund it where applicable. The body also carries result_url and the public job, so a client that logs only request_id can find the row later in the dashboard Jobs tab.

What does the job say when I poll it?

The public job error is deliberately more generic than the 400 message. For invalid_provider_input the job reports the message Invalid generation input., category: validation, stage: validation, retryable: false, public_reason: invalid_input and next_action: fix_input. If you need the specific sentence, keep the one from the 400 body.

Do not treat the failed job as something to wait on. It is terminal, and GET /v1/jobs/{id}/result on a failed job answers 409 job_not_completed-class conflicts rather than a result, so read the job record instead.

Which Idempotency-Key do I send after fixing it?

Use a new one. The same key with a different body is 409 idempotency_conflict by the documented rule, and on the routes that read the stored job back on a repeat, the same key with the same body re-raises the stored failure instead of trying again. A corrected request is a different operation, so give it its own key.

A short rule for a client: on invalid_request, look for details.request_id. If it is present, log it, show the user the message, and do not retry. If it is absent, nothing exists, and the fix is the same.