Poll or callback for 1,000 video jobs: request counts at 30 seconds
At a 30-second poll, 1,000 video jobs make 4,000 to 20,000 status requests by job time. A callback_url cuts that to 1,000 deliveries plus a sweep.

A 1,000-job library polled every 30 seconds makes 2 requests per minute of job time per job: 4,000 status requests if each job takes 2 minutes, 10,000 at 5 minutes and 20,000 at 10 minutes. With callback_url, Sume POSTs once per terminal job, so the same library needs about 1,000 deliveries plus a small sweep for the ones that never arrive.
The job durations here are examples for the arithmetic, not measured Sume figures; the Video generation docs say a video usually takes from 30 seconds to several minutes depending on model and parameters. Measure your own from the job timestamps.
The request counts
The poll count per job is job time divided by the poll interval, rounded up. The Video generation docs suggest a moderate interval of about 30 seconds.
| Job time | Polls per job | Total polls | Submits plus polls |
|---|---|---|---|
| 2 min | 4 | 4,000 | 5,000 |
| 5 min | 10 | 10,000 | 11,000 |
| 10 min | 20 | 20,000 | 21,000 |
What callback_url changes
Add callback_url to the /v1/videos request body. It must be HTTPS, and the API rejects localhost, private-network and non-HTTPS URLs. When the job reaches a terminal state, Sume POSTs a signed job envelope with x-sume-webhook-timestamp and x-sume-webhook-signature headers.
Delivery is up to 10 attempts, 30 seconds apart, with a 10-second timeout per attempt. The docs call delivery an optimization and say to keep the status polls available for events that never arrive. A receiver should therefore store the event first, answer with a 2xx, and treat job_id as its own idempotency key.
The peak request rate
The total hides the peak. If you submit all 1,000 jobs at once and poll each every 30 seconds, the steady rate is 1,000 / 30 = 33.3 requests per second while they are all in flight. In waves of 50 jobs it is 50 / 30 = 1.7 requests per second.
Sume answers 429 rate_limited when a window is exceeded and sends retry-after and ratelimit-* headers; its docs tell clients to back off and honor retry-after. A wave size that keeps the poll rate low also keeps the queue within the workspace capacity, so one setting controls both.
A hybrid that keeps the request count low
Use the callback as the main path and a sweeper as the safety net. The sweeper reads the table of jobs still pending after a threshold, say 15 minutes, and polls only those. If 1 percent of 1,000 jobs miss their callback, the sweep is 10 polls per cycle, not 1,000.
Keep the polling code even if you plan to go callback-only. Sume's docs say delivery is not the only recovery path, and a receiver that is down for a deploy will miss events.
- Use polling for under 50 jobs, a script, or a laptop with no public URL.
- Use callbacks for libraries, queues, and anything that runs unattended.
- Never hold an HTTP request open for the job; wait in your own worker.
Sources
Related posts
More in Developers
- Poll /v1/jobs/{id}/status, then /result, in Node with backoff
A 25-line Node function that polls a Sume job on its own next_poll_after_seconds, reads /result only when the job completed, and keeps the id on timeout.
- Polling a 5-minute video job: 150 GETs at 2 s, or 10 at 30 s
A five-minute Sume video job costs 150 status reads at a 2 s interval and 10 at 30 s. Poll /v1/videos with a loop that handles every status.
- Polling Omni jobs can't 429 your submits on Sume
Sume gives each API key separate read and write budgets: 120 writes and 4,800 reads a minute on Free, 1,200 and 48,000 on Scale. The math for an Omni batch.
- Port an OpenRouter video client to Sume: base URL, key, model ids
Sume's /v1/videos follows the OpenRouter video wire. Three edits move a client: base URL, API key, bare model id. The six differences that still bite.
Written by Sume