Which id to send Sume support: req_, job_, arun_ or agrun_

Send the request_id from the error body first, then the id of the job or run it concerns. Sume error bodies include a request id that is safe to share, and the Formats docs say the API also returns it as the x-sume-request-id header. Never include API keys, signed URLs, raw media URLs, or private workspace and user ids.

Sume uses several id prefixes, and knowing which surface each belongs to saves a round trip.

Two request ids on a run

On a run webhook, the envelope's request_id equals the run id and is stable across retries. The nested payload.request_id is a correlation id for the call that built the receipt: in a webhook it is the run id, while on GET /v1/format-runs/{run_id} it is an HTTP req_ id. Dedupe on the envelope value and ignore the nested one.

A run id will not resolve on the wrong surface. An Action or Format run id returns 404 agent_run_not_found on the Agent Completions routes, and a job id cannot be used as a run id or the reverse.

What a good report contains

Keep it short and mechanical so that support can look it up without guessing.

• The request_id of the failing response and its HTTP status.
• The job or run id, and the time you submitted it (UTC).
• The Idempotency-Key you used, if it is not secret to you.
• For a webhook problem, the x-sume-webhook-secret-fingerprint value, which is the only part of the secret that is safe to paste.
• The last public job events from GET /v1/jobs/{id}/events, which hide raw provider ids.

What to leave out

Do not paste the API key, a signed media URL, or the signing secret. If a key shows up in a log or chat, rotate it. The public API also hides provider names and storage keys, so a report that includes them was probably copied from somewhere that is not the public response.

Logging so you have the ids

Log the request_id of every non-2xx response and the job or run id of every successful submit, at the point where you receive them. When a customer reports a problem, the search is then one id, not a time window. Include the idempotency key you derived, because it links a retry to its original.

For webhooks, log the envelope request_id, the event name and the delivery fingerprint header. Do not log the raw body if it may contain customer content you do not need to keep.

Treat this as a habit, not a one-time fix. Write the rule down next to the code that calls the API, add a test that exercises it, and review it whenever the docs change. Check the linked documentation pages in the sources list for the current wording before you rely on any number here, because limits and field names can be revised, and a short test run costs far less than debugging a production incident.

When something does not match what you read here, capture the x-sume-request-id response header and the job or run id, and send those to support. Do not paste API keys, signing secrets or full request bodies into a ticket or a chat; the ids are enough for the team to find the request.