Debug a migrated video pipeline with Sume job events
When a replaced Sora pipeline stalls, read GET /v1/jobs/{id}/events: created, queued, started, completed or failed, and webhook delivery in one timeline.

When a migrated video pipeline hangs, read the job's event list before you guess. The jobs guide says GET /v1/jobs/{id}/events gives a public timeline for debugging and recovery: job.created, job.queued, job.started, generation.submitted, job.completed, job.failed, job.canceled and webhook.delivery. The pattern of those events tells you whether the problem is capacity, the render, or your receiver.
Read the timeline like a checklist
Each missing step points at a different cause.
| You see | Meaning | Next step |
|---|---|---|
| job.created, job.queued, nothing else | Waiting for a processing slot | Check generation_limits; not a failure |
| job.started, no terminal event | Render in progress | Keep polling; do not resubmit |
| job.completed, webhook.delivery failing | Render finished, your endpoint is the problem | Fix the receiver, then redeliver |
| job.failed | Public error on the job | Read the error category |
| No events for your id | Wrong key or workspace | Check key ownership; jobs are member-scoped |
The webhook leg
A job can be done while the callback is not. Sume sends up to 10 attempts, 30 seconds apart by default, with a 10 second timeout, per the webhooks guide. Delivery status is pending, delivering, delivered, retrying, failed or exhausted, and the attempt count is visible on the job object. After attempts are exhausted, POST /v1/jobs/{job_id}/webhook/redeliver re-sends the real terminal event with a fresh signature.
A small diagnostic habit
Log the job id at submit, and make support tooling accept a job id and print its status and events in one view. Store request_id from error responses too. Events never expose raw provider task ids or URLs, so what you read is safe to paste into a ticket, apart from your own signed URLs and keys.
What events cannot tell you
Sume exposes queue counts and capacity, not a per-job queue position or ETA, as the admission guide notes. Events are a pull snapshot, not a stream; there is no SSE or WebSocket transport. Poll them on demand when debugging, not in a tight loop.
Sources
Related posts
More in Developers
- Compute Sume job headroom from generation_limits, not a hardcoded 4
Read generation_limits from each Sume submit response and size new work with max(0, concurrency_limit - active - queued). Python example, with the docs numbers.
- Recraft V4.1 Flash: median 1.3 s, p95 1.8 s. Set timeouts from p95
Recraft quotes a median of about 1.3 seconds and a p95 of 1.8 seconds for V4.1 Flash. How to turn latency claims into timeouts and polling for image APIs.
- Recraft V4 on Sume returns WebP only: convert to PNG with Pillow
Recraft V4 on Sume lists webp as its only output format at $0.05 per image. Download the file and convert to PNG or JPEG with Pillow in six lines.
- Redeliver a missed speech-to-text webhook without rerunning the job
Your receiver was down when a Sume STT job finished. Redeliver the terminal webhook with one call instead of paying to transcribe again.
Written by Sume