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.

5 min readSume
All posts

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.

Status requests for 1,000 jobs at a 30-second poll (example job times; interval from the Sume docs, as of 2026-10-08)
Job timePolls per jobTotal pollsSubmits plus polls
2 min44,0005,000
5 min1010,00011,000
10 min2020,00021,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

All Developers posts

Written by Sume