202 Accepted to kod statusu HTTP należący do grupy 2xx (odpowiedzi sukcesu), który informuje klienta, że serwer przyjął żądanie do przetworzenia, ale samo przetwarzanie jeszcze się nie zakończyło — i może nie zakończyć się nigdy. To subtelna, lecz istotna różnica w stosunku do popularnego kodu 200 OK, gdzie odpowiedź oznacza pełne wykonanie operacji.
- 202 Accepted sygnalizuje przyjęcie żądania, nie jego realizację.
- Typowy kod dla operacji asynchronicznych i kolejkowania zadań.
- Serwer nie zobowiązuje się do wyniku — może zakończyć się sukcesem lub niepowodzeniem.
- Nie mylić z 200 OK (operacja zakończona) ani 201 Created (zasób już utworzony).
Jak 202 Accepted działa w praktyce
Mechanizm działania kodu 202
Kod 202 Accepted pojawia się, gdy serwer odbiera żądanie HTTP (najczęściej POST lub PUT), umieszcza je w kolejce do późniejszego wykonania i natychmiast odsyła odpowiedź klientowi. Klient nie musi czekać na zakończenie całej operacji — serwer “kwituje” przyjęcie zadania i zwalnia połączenie. Takie podejście jest fundamentem architektur asynchronicznych, gdzie czas przetwarzania mógłby wynosić sekundy, minuty lub nawet godziny.
Specyfikacja HTTP (RFC 9110) nie narzuca żadnego konkretnego formatu ciała odpowiedzi przy kodzie 202, ale dobrą praktyką jest zwrócenie informacji o statusie zadania lub adresu URL, pod którym można sprawdzić postęp operacji (tzw. polling endpoint lub odniesienie do zasobu statusu).
Kiedy serwery zwracają 202 zamiast 200?
Kod 202 sprawdza się wszędzie tam, gdzie natychmiastowa odpowiedź jest niemożliwa lub nieekonomiczna. Przykłady z realnych systemów:
- Kolejkowanie wiadomości e-mail — API przyjmuje żądanie wysłania maila, ale faktyczna wysyłka odbywa się przez serwis w tle (np. Amazon SES, SendGrid).
- Przetwarzanie plików wideo — upload pliku kończy się kodem 202, a transkodowanie trwa kolejne minuty.
- Generowanie raportów — system przyjmuje zlecenie wygenerowania raportu i odsyła 202; gotowy plik pojawia się pod wskazanym URL po zakończeniu pracy.
- Operacje bankowe i płatności — zlecenie przelewu zostaje przyjęte do realizacji, ale rozliczenie następuje asynchronicznie.
- Harmonogramowanie zadań (job scheduling) — żądanie uruchomienia procesu batchowego trafia do kolejki, np. RabbitMQ lub Apache Kafka.
Czym różni się 202 Accepted od 200 OK i 201 Created?
Trzy kody z grupy 2xx brzmią podobnie, ale mają precyzyjnie odmienne znaczenia. Zestawienie w tabeli poniżej pozwala szybko ocenić, który kod zastosować w danym scenariuszu API.
| Kod | Nazwa | Co oznacza | Typowe użycie |
|---|---|---|---|
| 200 | OK | Żądanie wykonane w całości | GET zwracający dane, synchroniczny POST |
| 201 | Created | Zasób został utworzony | POST tworzący nowy rekord w bazie |
| 202 | Accepted | Żądanie przyjęte, przetwarzanie w toku | Asynchroniczne zadania, kolejki |
Jak poprawnie zbudować odpowiedź 202?
Dobra odpowiedź 202 powinna zawierać w ciele (body) informacje, które pozwolą klientowi śledzić status zadania. Minimalistyczny przykład w formacie JSON wygląda następująco:
HTTP/1.1 202 Accepted
Content-Type: application/json
{
"status": "queued",
"task_id": "f3a92b1c-4d8e-11ef-a7b0",
"status_url": "https://api.example.com/tasks/f3a92b1c"
}
Pole status_url wskazuje endpoint, który klient może odpytywać (polling) w celu sprawdzenia, czy zadanie dobiegło końca. Alternatywą jest mechanizm webhooków — serwer sam powiadamia klienta o zakończeniu operacji, bez potrzeby wielokrotnych zapytań.
Znaczenie dla SEO i widoczności
Z perspektywy pozycjonowania stron kod 202 jest neutralny dla Googlebota — robot indeksujący traktuje go jako potwierdzenie przyjęcia żądania, a nie jako stronę do zaindeksowania. Problemy zaczynają się wtedy, gdy 202 jest błędnie zwracany zamiast 200 na stronach przeznaczonych do indeksowania. Googlebot może wówczas nie zindeksować treści lub zinterpretować odpowiedź jako sygnał, że strona nie jest gotowa.
W kontekście API i aplikacji headless (np. Next.js, Gatsby z zewnętrznym CMS) poprawne użycie 202 jest ważne podczas prerenderowania i pobierania danych. Jeśli endpoint API zwróci 202 zamiast 200 przy próbie pobrania treści przez renderer, strona może zostać wyrenderowana jako pusta — z bezpośrednim wpływem na indeksowanie i ranking. Warto to weryfikować podczas audytu SEO projektów opartych na architekturach API-first.
FAQ
Czy 202 Accepted oznacza błąd?
Nie — kod 202 należy do grupy 2xx, która oznacza sukces komunikacji między klientem a serwerem. Serwer poprawnie odebrał żądanie i przyjął je do realizacji. Nie ma tu błędu, choć operacja docelowa może się jeszcze nie zakończyć lub zakończyć niepowodzeniem w przyszłości — to już zależy od logiki aplikacji, nie od protokołu HTTP.
Jak klient powinien reagować na odpowiedź 202?
Klient powinien zapamiętać identyfikator zadania lub adres URL statusu zwrócony w ciele odpowiedzi, a następnie odpytywać ten endpoint w regularnych odstępach czasu (polling) lub oczekiwać na powiadomienie przez webhook. Bez tych mechanizmów klient nie ma możliwości sprawdzenia, czy operacja zakończyła się sukcesem.
Czym różni się 202 od 204 No Content?
Kod 204 No Content oznacza, że serwer wykonał żądanie w całości i celowo nie zwraca żadnej treści w odpowiedzi — operacja jest zakończona. Kod 202 Accepted sygnalizuje natomiast, że operacja jeszcze trwa lub dopiero zostanie uruchomiona. To fundamentalna różnica: 204 to koniec, 202 to zatwierdzenie startu.
Kiedy nie używać kodu 202?
Nie stosuj 202, gdy operacja jest wykonywana synchronicznie i jej wynik jest dostępny od razu — wtedy właściwym kodem jest 200 OK lub 201 Created. Zwracanie 202 w takich przypadkach wprowadza niepotrzebne skomplikowanie po stronie klienta i może powodować problemy z integracjami, które oczekują natychmiastowego wyniku.
Kiedy 202 Accepted naprawdę robi różnicę
Poprawne użycie kodu 202 to nie tylko kwestia zgodności ze specyfikacją HTTP — to świadoma decyzja architektoniczna, która wpływa na wydajność, niezawodność i skalowalność systemu. W Webiti zwracamy uwagę na poprawność kodów HTTP podczas audytów technicznych, szczególnie w projektach e-commerce i aplikacjach API-first, gdzie błędne kody potrafią niepostrzeżenie obniżyć widoczność w Google. Jeśli chcesz mieć pewność, że Twoja strona lub sklep działają technicznie bez zarzutu, sprawdź ofertę audytu SEO lub pozycjonowania stron w Webiti.
