202 Accepted oznacza, że serwer przyjął żądanie, ale go nie zrealizował – i może w ogóle go nie zrealizować. HTTP nie przewiduje sposobu, by później zgłosić wynik pracy wykonywanej w tle, dlatego kod 202 celowo do niczego nie zobowiązuje.
Stosuje się go przy zadaniach wsadowych, eksportach, transkodowaniu wideo, kolejkach wiadomości i innych operacjach wykonywanych w tle. Dobra odpowiedź 202 mówi klientowi, co robić dalej: podaje adres URL, pod którym można sprawdzić stan zadania (w treści lub w nagłówku Location), oraz szacowany czas jego zakończenia, czasem w nagłówku Retry-After.
Klienci traktują kod 202 jako sukces. Na przykład nadawcy webhooków akceptują go, tak jak każdy kod 2xx, jako potwierdzenie odebrania zdarzenia.
Przykładowa odpowiedź
HTTP/1.1 202 Accepted
Date: Fri, 06 Nov 2026 10:15:32 GMT
Location: https://api.example.com/v1/exports/3f9c
Retry-After: 30
Content-Type: application/json
Content-Length: 31
{"id":"3f9c","status":"queued"}SEO i sprawdzanie przekierowań
Kod 202 nie ma racji bytu na stronach przeznaczonych dla wyszukiwarek. Roboty traktują go jako sukces, ale zwykle nie ma tam nic do zaindeksowania. Beacony analityczne i endpointy śledzące często zwracają 202 lub 204 i jest to w porządku, bo roboty nie indeksują ich jako stron.
Typowe przyczyny i zastosowania
- API dodało do kolejki długotrwałe zadanie i zwraca adres URL, pod którym można odpytywać o jego stan.
- Odbiorca webhooka od razu potwierdza zdarzenie, a przetwarza je później.
- Endpoint do logowania lub analityki przyjmuje dane, nie potwierdzając, że zostały zapisane.