202 Accepted indica che il server ha accettato la richiesta ma non l’ha completata, e potrebbe anche non completarla affatto. HTTP non offre alcun modo per comunicare in seguito il risultato di un’elaborazione in background, per questo il 202 è volutamente vago.
Si usa per job batch, esportazioni, transcodifica video, code di messaggi e altre attività eseguite in background. Una buona risposta 202 indica al client come proseguire: un URL dove controllare lo stato (nel corpo o in un’intestazione Location) e una stima di quando il lavoro sarà terminato, a volte con Retry-After.
I client trattano il 202 come un successo. Chi invia webhook, per esempio, lo accetta come qualsiasi codice 2xx, a conferma che l’evento è stato ricevuto.
Esempio di risposta
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 e verifica dei redirect
Il 202 non ha senso sulle pagine destinate ai motori di ricerca. I crawler lo trattano come un successo, ma di solito non c’è nulla da indicizzare. I beacon di analytics e gli endpoint di tracciamento restituiscono spesso 202 o 204, e va bene così, perché non vengono scansionati come pagine.
Cause comuni e casi d’uso
- Un’API ha messo in coda un job di lunga durata e restituisce un URL da interrogare per conoscerne lo stato.
- Un ricevitore di webhook conferma subito la ricezione di un evento e lo elabora in seguito.
- Un endpoint di logging o di analytics accetta i dati senza confermare che siano stati salvati.