Stripe events arrive out of order; Sume sends only terminal job events
Stripe does not order events and says to dedupe on event ID. Sume sends only terminal job events keyed by job_id, so order rarely matters. Fetch state.
Stripe says events are not delivered in order and that you should dedupe on the event ID. Sume sidesteps most of that problem by sending only terminal job events (job.completed, job.failed, job.canceled), once per job. You still should not trust arrival order, but you can make every handler order-independent by reading the job instead.
The comparison below is built from Stripe's webhook page and Sume's webhook and jobs docs.
What each provider says
| Item | Stripe | Sume |
|---|---|---|
| Ordering | Events are not ordered | No ordering promise in the docs I read |
| Dedupe key | Event ID | job_id |
| Event types | Many event types | Three terminal events; no progress or partial deliveries |
| Retries | Live mode up to 3 days with exponential backoff | 10 attempts, fixed 30 s |
| Pull alternative | Not covered here | GET /v1/jobs/{id}/status and /result; /events is a pull snapshot |
Why terminal-only helps
Out-of-order trouble mostly comes from lifecycle events: a 'started' arriving after 'completed'. Sume's event set has no such pair. A job reaches exactly one terminal state, and the event reports it. If a job.completed and a job.failed ever both reached you for the same job_id, your store should keep the status you read from GET /v1/jobs/{id}/status, because that endpoint is the source of truth.
Order-independent handler
- Treat the webhook as a notification, not as the state. On receipt, read the job from Sume and update your row from that.
- Upsert by job_id. A second delivery of the same event should change nothing.
- Never use arrival time as the business timestamp. Use fields you stored at submit time.
- Use the events endpoint (job.created, job.queued, job.started, generation.submitted and the terminal events) when you need a timeline for debugging. Public events do not expose raw provider ids.
Late deliveries
A Sume retry arrives about 30 seconds after the failed attempt, and a redeliver can arrive at any time, so a late job.completed is normal. The signature timestamp is fresh each time, but the job_id is not, which is why dedupe belongs on job_id. See the Sume webhooks docs.
Sources
Related posts
More in Developers
- Stripe retries webhooks for 3 days, Sume job webhooks for 4.5 minutes
Compare retry windows: Stripe live mode retries up to three days; Sume job webhooks use 10 attempts at 30s spacing. Size your poll fallback to the shorter one.
- Pick a caption style from the STT language_code before you burn
Run Sume STT on the detached audio, read language_code, and choose korean-ad or slam before POST /v1/video-captions. Avoids the Hangul-on-Latin 400.
- STT with no punctuation: Sume still cuts sentence segments on silence
Sume STT's sentence segmentation splits on terminal punctuation, and on silence when a run has none. What boundary_lead_ms 70 does and a Python call.
- STT words into caption words: rename word to text, stay under 60 s
Sume STT returns words as {word, start, end}; the caption job wants {text, start, end}, end above start, 60 s or less, 1200 words at most. Map and filter.
Written by Sume