Report a failed Sume video job: share the request id, not the URLs

When a video job fails and you need help, send two identifiers and leave everything else out: the request_id from the error body, and the job id. Sume's error docs say the request id is safe to share with support, and they list what should stay private: API keys, signed URLs, raw media URLs, and private workspace or user ids.

That sounds obvious, but the usual support ticket for a failed render pastes the whole curl command, including the bearer token and the image URL it fetched. This note gives a three-line checklist and shows where each value comes from.

Where the identifiers live

Public error bodies have an error object with code, message, request_id and details. The same request id is also exposed in the response headers. A failed job additionally exposes public error metadata, such as category, stage, retryability, retry-after seconds, public reason and next action. Internal provider payloads are not public API fields, so there is nothing more to dig out of the response.

Read the failure before you write the ticket

Check the error field on the poll response first; the video docs tell you to do exactly that. Then read the job's public timeline at GET /v1/jobs/{id}/events, which lists names such as job.created, job.queued, job.started, generation.submitted and job.failed. The category often answers the question without a human: validation means fix the input, quota means add funds or lower the cost, queue means retry later with the same idempotency key.

A failed job or a failed queue admission releases or refunds the reservation where applicable, so a failure alone is not a reason to dispute a charge. If usage looks wrong after a failure, include the job id and say what you expected.

Do not retry by resubmitting

If your client timed out locally, keep polling the same job id. If you must retry the submit, reuse the same Idempotency-Key so the retry returns the original job rather than billing a second one. A new key is a new paid job.

A template for the report

A good report is five lines. The job id. The request id from the error body. The model id you pinned, or sume/auto. The time you submitted, in UTC. And one sentence about what you expected. Add the error.code and the category if the job failed rather than the request. That is enough for a person to find the record without any secret leaving your system.

If you are a developer building a product on top of the API, put the request id in your own error screen so that your users can quote it back to you. It is safe to share, and it saves a round trip every time.

Limits

This is guidance from the public docs, not a statement about how fast support replies. The docs also state that responses are provider-neutral, so a ticket will not need a vendor task id and you will not find one in the API.