HeyGen API concurrency limit: 1.5x burst vs Sume queued jobs

HeyGen Enterprise workspaces can set an extra concurrency cap of up to +50; workflows admitted while every included slot is busy bill at 1.5x the contract rate, and requests beyond included plus extra return 429. The Sume docs describe no pay-per-use burst tier: concurrency is a dispatch limit set by plan (admin overrides can raise it), extra valid jobs wait as queued, and a 429 queue_full appears only when the queue is also full.

HeyGen facts are from its September 2026 changelog; Sume facts are from Generation admission, read 2026-09-30.

How does HeyGen burst work?

The cap applies separately to avatar renders and video translations. Only workflows that actually land above the included slots pay the premium, and they are tagged Burst in the Activity tab. It is enabled per workspace by the account team.

What happens above the limit on Sume?

The docs state that concurrency being full is not an error by itself. A job moves queued to processing as a slot opens. Concurrency is plan-only and prepaid top-ups do not raise it.

What does that mean for a 100-video batch?

On Pro, accepted capacity is 24 paid jobs at once, so 100 submits at the same moment would hit 429 queue_full after the first 24. Submit in waves, store each job_id, and retry a rejected submit with the same idempotency key once jobs finish. There is no premium rate for waiting, only the delay.

Which approach fits a spiky workload?

Burst suits a short spike where finishing sooner is worth a premium. Queueing suits work that can wait. Details of the Sume side are in queue full 429 vs concurrency full.