Sume request id: what to share with support and what to leave out
Every Sume error body and header carries a request id that is safe to share. Do not include API keys, signed URLs, raw media URLs or private workspace ids.
Sume error bodies include a request id that is safe to share with support, and it also appears in response headers (read 2026-10-06 in the errors docs).
What belongs in a support message?
The request_id, the endpoint, the time, and the status code. Leave out API keys, signed URLs, raw media URLs and private workspace or user ids.
{
"error": {
"code": "invalid_request",
"request_id": "req_..."
}
}What should I do in practice?
That is all support needs to start.
- Log the request id on every failure.
- Redact secrets in logs.
- Include job id for generation issues.
Sources
Related posts
More in Developers
- Sume idempotency: JSON key order is ignored, array order is not
Resending a Sume job with the same fields in a different JSON key order still returns the original job. Changing an array's order or a value gives a 409.
- How long does a Sume Idempotency-Key last? The docs don't say
The Sume docs describe Idempotency-Key replay and the 409 conflict but give no lifetime. What is documented, what is not, and a safe way to design around it.
- Sume image_not_fetchable: make the input a public HTTPS image URL
image_not_fetchable and input_media_unreachable mean Sume could not fetch or mirror your media safely. Use a public HTTPS URL and retry.
- Sume job error categories and the next action for each
Failed Sume jobs carry a category: validation, auth, quota, queue, generation_unavailable, generation_rejected, timeouts, runtime_unavailable or internal.
Written by Sume