Long polling vs short polling: what's the difference?

Short polling sends a request on a timer, and the server answers at once, even when nothing has changed. Long polling sends a request that the server holds open until there is news or a timeout, and the client typically asks again as soon as it gets the answer. Long polling aims to cut delivery delay and wasted requests; the price is a request held open per client, kept short enough to end before proxy timeouts do.

The definitions come from RFC 6202, the IETF's informational RFC on long polling, and MDN's WebSocket API and Server-sent events pages. The Sume waits come from its Jobs and results and Authentication docs. All were read on 2026-09-28.

How does long polling differ from short polling?

In short polling, each request pulls whatever is available. If nothing is, the server returns an empty response and the client waits before polling again. How often you poll depends on how much delay you can tolerate, and a low tolerance means many requests. In long polling, the server responds only when an event, a status change or a timeout occurs. The client typically sends a new long poll right away, so the server almost always holds one open.

What are the downsides of long polling?

RFC 6202 describes these costs:

• Held resources. Each waiting client holds a TCP connection and an HTTP request open, and some gateways, proxies and servers limit how many requests can be outstanding.
• Timeouts in the middle. Hold a request too long and the client may get a 408 Request Timeout from the server or a 504 Gateway Timeout from a proxy. The RFC reports success with timeouts as high as 120 seconds, but calls 30 seconds generally a safer value.
• Header overhead. Every long poll request and response is a complete HTTP message with a full set of headers, which can be a large share of the data for small, infrequent messages.
• Worst-case delay. News that arrives just after a response has to wait for the next request.

Which should I use for a job that takes minutes?

Neither holds one request that long. RFC 6202 calls 30 seconds a generally safer long-poll timeout, so a wait of minutes becomes a series of requests: short polls spaced out with backoff, or long polls repeated one after another. A server can also skip waiting and take a webhook. Sume's API offers each, with its own limit; image jobs often finish inside its 30-second submit wait, and video jobs routinely do not.

• Short polls: read GET /v1/jobs/{id}/status, sleeping next_poll_after_seconds when it's present or backing off exponentially, until terminal is true. Reads have their own budget, forty times the write budget, so a tight status-poll loop can't 429 your own submits. How to poll a video generation job status API shows the loop.
• A bounded wait on the submit: on routes that take a mode, mode: "sync", or its alias subscribe, holds the create for at most 30 seconds, and less when waiter capacity is unavailable. Not terminal by then? Poll; don't resubmit. Sync vs async lists the routes that differ.
• Repeated long polls: the hosted MCP jobs_wait holds one call for at most 55 seconds, 50 by default. The docs say every edge eventually closes a request held open with nothing transferring, so wait out a ten-minute render by repeating the wait, not by asking for a longer one. See MCP tool call timeouts.
• A webhook: skip waiting and let Sume POST the terminal event to your server, as in Webhook vs API.

What about WebSockets and server-sent events?

Both let the server send news without waiting to be polled. A WebSocket is a two-way session in which the browser can send messages and receive responses without polling for a reply. Server-sent events let a server push new data to a web page at any time. Sume's Developer API offers neither today, and its GET /v1/jobs/:id/events is a pull snapshot, not a stream; React Query polling shows how a browser page waits instead.