504 Gateway Timeout from an API: did my request go through?

A 504 Gateway Timeout from an API means a gateway or proxy between you and the API server stopped waiting for the server's answer. It does not mean the server rejected your request: the work may have been accepted and may still be running. So don't resend a request that creates or bills something until you have checked. For long work, submit asynchronously with an idempotency key and poll for the result instead of holding one request open.

The status code definitions come from RFC 9110, the HTTP semantics standard. The worked example is Sume's job API, from its Jobs and results docs. Both were read on 2026-09-28.

Whose timeout fired?

Not the API's. RFC 9110 defines 504 as a server, acting as a gateway or proxy, that did not receive a timely response from the upstream server it needed. The 504 is written by whatever sits in the middle: a load balancer, a CDN, an API gateway, or your own reverse proxy. That is also why a 504 body may not look like the API's usual JSON error.

Did my request still go through after a 504?

Maybe, and you can't tell from the 504. What you do next depends on whether you already have an id for the work:

• You have a job id: poll it. Sume's docs say to keep the job id and recover with the jobs API instead of submitting duplicate paid work. A client-side timeout does not cancel the job; it keeps running and still bills.
• You have no id, because the 504 answered a submit that carried an idempotency key: retry it with the same Idempotency-Key and the same body. On Sume's POST /v1/videos, a replay returns the original job, so the retry doesn't start a second paid one.
• You sent no idempotency key: look before you resend. On Sume, GET /v1/jobs lists jobs, so you can check whether the first attempt created one.

# A retry after a 504: same key, same body, same job
curl -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: desk-pan-2026-09-28-001" \
  -d '{"model": "sume/auto", "prompt": "A slow pan across a desk at sunrise"}'

Why do long API calls return 504?

Because a request held open with nothing transferring looks idle to everything in between. Writing about its hosted MCP waits, Sume's docs say every edge closes such a request eventually, and that a request held for 600 seconds dies at the edge (502 / Transport send error) before it can answer. Video jobs routinely outlast even a 30-second wait.

An API can avoid the gateway timeout by never holding the request that long. Sume caps the blocking wait on a submit at 30 seconds. When the wait runs out, the response is still a 2xx with the job id, and the docs say you must not submit a new paid job for the same intent.

How do I stop getting 504s on long jobs?

• Submit asynchronously. Sume's default async mode returns 202 with the job envelope right away, as the asynchronous request-reply pattern describes.
• Send an Idempotency-Key on every submit, so a retry returns the original job instead of billing a second one.
• Poll status_url with short requests, honoring next_poll_after_seconds, or take a webhook and keep polling as the backup.
• Put your long deadline in your own client, not in one HTTP request. Video generation API timeouts lists Sume's caps and the SDK defaults.