2026-09-29

fal subscribe equivalent for a video API: Sume has no SSE

Sume accepts mode subscribe but it is an alias of sync: one 30-second wait, no event stream. For a fal-style long wait, submit async and poll status.

4 min readSume

All posts

The closest thing to a fal-style subscribe() on Sume is a client-side loop: submit with mode: "async", poll the job status until it is terminal, then read the result. Sending mode: "subscribe" is accepted but it is only an alias of sync, and the Developer API has no SSE or WebSocket transport today.

What does mode subscribe do on Sume?

It runs the same bounded waiter as sync and returns the same envelope. It is kept because clients ported from other queue APIs reach for it. It is not a long-lived subscription, an event stream or a longer wait, and GET /v1/jobs/:id/events is a pull snapshot, not a stream. For progress, submit async and read that events route, or take a webhook.

Which subscribe am I looking at?

The word appears on three surfaces in the docs, and none of them is a push stream.

Three meanings of subscribe in the Sume docs, read 2026-09-29.
Where	What it is
Job `mode: "subscribe"`	An alias of sync: one bounded HTTP wait on the submit call, capped at 30s.
SDK `subscribeFormatRun()`	Creates the run, then polls it client-side; the timeout is the SDK's own, not an HTTP hold.
Format run `communication.mode`	Delivery selection for a run; the values are async and webhook, and subscribe is not one of them.

How do I get a long wait?

Put the wait in your client. Submit with async and an Idempotency-Key, poll GET /v1/jobs/{id}/status until terminal is true (honoring next_poll_after_seconds or backing off), then GET /v1/jobs/{id}/result. The timeout is yours to set, so it can be minutes without holding an HTTP request open.

The status route also returns a queue-shaped status field (IN_QUEUE, IN_PROGRESS, COMPLETED, FAILED, CANCELED) that maps one-to-one onto sume_status, which helps a client ported from another queue API. In TypeScript, the SDK's wait helpers are this loop; see wait for jobs and runs in the Sume SDK.

What if my code depends on progress events?

Sending subscribe does not get you them. Poll the status or events routes, or use mode: "webhook", which delivers only the terminal callbacks; there are no progress webhooks. Full detail is in Jobs and results.

Will subscribe be removed?

The docs say sync and subscribe remain supported and are not going anywhere; they are just the wrong tool for anything that can outlast 30 seconds, which is most video work. New integrations should reach for async, polling or reading events, or webhook, being told.

So a port from a queue client does not need to change every call site at once. If a call already sends subscribe, it keeps working as the same bounded wait. The change that matters is the handling after the wait: check terminal on the envelope and poll when it is false, rather than assuming the response holds the finished result.

Sources

Jobs and results