202 vs 204: Accepted vs No Content

204: Synchronous Success Without a Result

204 No Content is the response when an operation completes immediately and there is nothing meaningful to return. The work is done. Deleting a resource, updating a record when you already know the new state, responding to a CORS preflight, acknowledging an autosave — all of these can return 204.

DELETE /api/items/55 HTTP/1.1

HTTP/1.1 204 No Content

The client sees 204 and knows: success, operation complete, move on. No polling. No callback. No job to track.

202: Asynchronous — Check Back Later

202 Accepted is the response when the server cannot complete the operation before sending the response. The request was valid and has been queued, but processing will happen later. The client must track the operation using the job ID or status URL in the response body.

POST /api/invoices/batch-send HTTP/1.1
Content-Type: application/json

{"invoiceIds": ["inv_1", "inv_2", "inv_3"]}

HTTP/1.1 202 Accepted
Location: /api/jobs/job_4k2m

{
  "jobId": "job_4k2m",
  "status": "queued",
  "statusUrl": "/api/jobs/job_4k2m"
}

The client polls the statusUrl to find out when the invoices have been sent. The 202 only confirms the request was accepted; the actual sending happens in the background.

Decision Rule

The rule is about timing: did the operation finish before you sent the response?

If yes → use 204 (or 200 if you have a result to return).

If no → use 202 with a job tracking mechanism.

A common mistake is returning 204 for operations that actually take several seconds in the background, falsely signaling to the client that the work is complete. Use 202 to give clients an honest signal about the actual state of processing.

FAQ

Can a DELETE return 202?

Yes. If the deletion requires background processing — cascading deletes across many records, archiving data before deletion, or queuing the operation for audit reasons — 202 is appropriate. The resource may still be accessible briefly after the 202 response while deletion propagates.

Should 202 always include a response body?

Yes if the client needs to track the operation. A 202 with no job ID or status URL is a “fire and forget” response — valid for truly one-way operations (analytics beacons, notifications), but unhelpful for operations where the client cares about the outcome.

Can 204 responses be cached?

204 is cacheable by default per RFC 9110, which is unusual for a success response with no body. In practice, DELETE and PATCH operations should include Cache-Control: no-store to prevent inappropriate caching, since a cached 204 for a resource that was re-created would be misleading.

Full Guides

HTTP 202 Accepted — full guide · HTTP 204 No Content — full guide · All comparisons

Related comparisons

• 201 vs 202
• 204 vs 205