202 Accepted vs 200 OK: is the job done yet?

200 OK means the request succeeded and the response carries its result. 202 Accepted means the server accepted the request for processing but hasn't finished it, and may not have started, so you learn the outcome later from a status URL or a webhook. On an API that generates video, don't treat either code as proof the video is ready: check the status field in the response body.

The HTTP definitions are quoted from MDN's 202 Accepted and 200 OK pages; the Sume behavior comes from the Jobs and results, Create a run and Image API docs. All were read on 2026-09-27.

What does 202 Accepted mean?

MDN calls a 202 non-committal: the request was accepted for processing, the processing may still fail or be disallowed, and HTTP has no way to send the outcome later as a second response. That is why an API that answers 202 gives you something to follow up with. MDN's own example returns a task id and a URL to monitor.

Sume's generation jobs work this way. The default async mode and the webhook mode answer 202 with the job envelope and polling URLs, and every mode returns the job id in its first response. In the docs' words, a 2xx means the job exists and paid work is in flight; it does not mean the job finished. POST /v1/videos is asynchronous too: its documented submit response is 202 Accepted with a job id and a polling URL.

When does an API return 200 instead of 202?

When the work finished inside the request, or when nothing new had to happen. Both show up on Sume, depending on the call. Sync vs async video generation covers the submit modes themselves.

Does a 200 mean my video is ready?

Not on a run create. A Format run replay returns 200 with the original run's receipt, and a schedule's 200 is either a replay or a skipped run; the code alone never tells you a video exists. The schedule docs put it plainly: 200 does not mean the work finished, so branch on the receipt's status field, not on the HTTP status.

On the image endpoint, the code itself tells you what you got: 200 is the image response and 202 is the job envelope, so check the status code, not the body shape. Slow configurations such as 4K, high quality or a large n are the ones most likely to come back 202; see why a 4K request returns 202.

const res = await fetch("https://api.sume.com/v1/images", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SUME_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ model: "sume/auto", prompt: "a red panda astronaut" }),
});
const body = await res.json();
if (res.status === 200) {
  console.log(body.data[0].url); // the finished image
} else if (res.status === 202) {
  console.log(body.data.status_url); // a job envelope: poll this
}

What should my code do after a 202?

Treat the 202 as a receipt, not a result:

• Store the id from the first response. Every mode returns it, and it is how your integration recovers the work after a restart.
• Poll with backoff. On a job envelope, poll status_url, honoring next_poll_after_seconds when it is present, until terminal is true, then read result_url once result_ready is true. POST /v1/videos hands you a polling_url instead. How to poll a job status API has the loop.
• Or send a webhook URL with the submit (webhook_url on a generation job, callback_url on POST /v1/videos) and wait for the terminal callback, keeping polling as the backup.
• Don't resubmit because your wait ran out. A client-side timeout does not cancel the job, which keeps running and billing. If you must retry the submit, reuse the same Idempotency-Key so the retry returns the original job.
• Expect failures on the receipt, not the status line. On Format runs, a 202 never turns into a create error later: a failure arrives on the receipt as status: "failed".