Bannerbear sync API 408 after 10 seconds vs Sume mode sync

Bannerbear offers a synchronous host, https://sync.api.bannerbear.com, that waits for the render inside the request but times out after 10 seconds with a 408. Sume's equivalent is mode: "sync" on routes that support it: it waits up to 30 seconds and returns 200 with the finished job, or 202 with the queued job to poll.

The difference is what a timeout means. Bannerbear's 408 is a timeout of the request; Sume's 202 after the wait is a normal outcome, not an error. Bannerbear details are from its API reference.

How does Bannerbear's sync endpoint behave?

The reference says the API is primarily asynchronous, with a 202 Accepted on POST and results by webhook or polling. For callers that need an answer in one request there is the sync host, which waits for generation but gives up after 10 seconds with 408. Everything else, including how to recover the render after a 408, is not stated on the page I read, so test it before relying on it.

How does Sume's sync mode behave?

On routes such as video trim, Timeline 1.0 render and video inspect, the mode field chooses the communication style. Video inspect defaults to sync; video trim and Timeline default to async. With mode: "sync" the handler waits up to 30 seconds. If the job finishes it answers 200; otherwise 202 with the job to poll. Video frames always answers 202, even if you ask for sync.

Because the job already exists when you get a 202, nothing is lost: poll GET /v1/jobs/:id/status until terminal is true, honouring next_poll_after_seconds, then read result_url once result_ready is true.

What does a client look like?

Write the client for both answers, and never treat 202 as an error.

curl -i -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: trim-sync-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/talk.mp4",
    "start": 2,
    "duration": 8,
    "mode": "sync"
  }'
# 200: read the result now. 202: poll the status_url in the body.

Should you use sync at all?

Use sync for short clips where the user is waiting, and webhook or polling for everything else. Sume's docs say a trim is worker ffmpeg with no provider inference, so short cuts often fit inside 30 seconds, but do not assume it. A load balancer or no-code tool with its own 30-second ceiling will cut you off at the same moment the wait expires, which is why many integrations stay on async and poll.

What are the edge cases?

Two are worth testing. First, a source that is slow to fetch: Sume admits a job and may spend the wait fetching, so a 202 can come back even for a short clip. Second, a client with a short timeout of its own: if your HTTP client gives up at 10 seconds, you will not see Sume's answer, but the job and its idempotency key still exist, so resubmitting with the same key returns the same job rather than a new one.

Prefer mode: "webhook" with a public HTTPS webhook_url when you cannot hold a connection open.

• Sync waits up to 30 seconds.
• Video frames always returns 202.
• Webhooks need a public HTTPS URL.