What Is 202 Accepted

Content on WhatAnswers is provided "as is" for informational purposes. While we strive for accuracy, we make no guarantees. Content is AI-assisted and should not be used as professional advice.

Last updated: April 15, 2026

Quick Answer: 202 Accepted is an HTTP status code indicating that the server has accepted the request for processing, but the action has not been completed. It is commonly used in asynchronous operations where the response will be available later.

Key Facts

202 Accepted was defined in RFC 7231 in 2014
Indicates the request is accepted but not yet processed
Used in asynchronous API workflows to defer processing
Common in webhooks and batch processing systems
Differs from 200 OK, which confirms immediate completion

Overview

The HTTP 202 Accepted status code signals that a server has received and accepted a request, but has not yet completed the action. Unlike 200 OK, which confirms immediate success, 202 indicates the server will process the request asynchronously. This status is particularly useful when operations take time, such as large data uploads or background jobs.

Defined in RFC 7231, the 202 status allows clients to understand that their request is valid and queued, even if results are not immediately available. It is part of the HTTP/1.1 standard and widely supported across modern web servers and APIs. Proper use improves user experience by acknowledging receipt without requiring long wait times.

Asynchronous processing: The 202 status enables servers to handle long-running tasks without blocking the client, improving system responsiveness and scalability.
Client acknowledgment: Clients receive confirmation that the request was received, reducing uncertainty about whether submission was successful.
Deferred execution: The actual processing may occur minutes or hours later, allowing systems to manage load and prioritize tasks efficiently.
Common in REST APIs: Many cloud services, such as AWS and Google Cloud, return 202 when initiating operations like instance creation or data migration.
Security and validation: The server may perform initial validation before returning 202, ensuring malformed requests are rejected early.

How It Works

When a client sends a request, the server can respond with 202 Accepted to indicate acceptance without immediate completion. This response typically includes a Location header pointing to a status endpoint or a Retry-After header suggesting when to check again. The client must then poll or receive callbacks to track progress.

Status Code: 202 is part of the 2xx success class, indicating the request was received and accepted, though not yet fulfilled.
Header Usage: Servers often include Location to direct clients to a status-checking endpoint, aiding in tracking asynchronous operations.
Retry-After: This optional header tells the client how long to wait before checking again, commonly set to 30 seconds or more.
Response Body: The body may contain a job ID, estimated completion time, or links to monitor progress, enhancing usability.
Use in Webhooks: Services like GitHub and Stripe use 202 when acknowledging webhook deliveries that trigger delayed processing.
Error Handling: If processing later fails, the server should provide an error status via the status endpoint, not in the initial 202 response.

Comparison at a Glance

Below is a comparison of 202 Accepted with other common HTTP status codes in asynchronous contexts:

Status Code	Meaning	Use Case
200 OK	Request succeeded and response is immediate	Standard GET or POST with instant results
201 Created	Resource successfully created	After POST requests that generate new entities
202 Accepted	Request accepted for processing	Long-running operations like data imports
204 No Content	Request successful, no response body	DELETE requests or silent updates
400 Bad Request	Client error due to malformed syntax	Invalid JSON or missing required fields

This table highlights how 202 differs from immediate success codes. While 200 and 201 confirm completion, 202 explicitly defers it. Understanding these distinctions helps developers design resilient APIs that manage client expectations and handle delays gracefully.

Why It Matters

202 Accepted plays a crucial role in modern web architecture, especially as systems grow more complex and distributed. By decoupling request receipt from processing, it supports scalable, non-blocking designs essential for cloud-native applications. Its proper implementation enhances reliability and user experience.

Scalability: Servers can offload work to background queues, preventing timeouts during high-traffic periods.
User experience: Clients receive immediate feedback, reducing perceived latency and improving interface responsiveness.
API design: Enables clean separation between request initiation and result retrieval, following REST best practices.
Error transparency: Allows systems to report processing failures later without misleading initial success.
Resource management: Helps balance server load by scheduling intensive tasks during low-usage windows.
Compliance: Used in regulated environments where audit trails require acknowledgment of receipt.

As web services continue to rely on asynchronous workflows, understanding and correctly using 202 Accepted becomes essential for developers and architects alike.