Feil og ratelimiter
Den ene feilenveloppen som hvert mislykkede forespørsel returnerer, ratelimit-hodene, og hvordan du kan prøve en skriving på nytt på en trygg måte.
Hvert endepunkt feiler på samme måte, så en klient håndterer feil, ratelimiter og omforsøk én gang og gjenbruker den koden overalt, inkludert over MCP.
Hvert ikke-2xx-svar er ett JSON-objekt:
{
"defined": false,
"code": "TOO_MANY_REQUESTS",
"message": "Too many requests",
"data": { "reason": "rate_limit.exceeded", "retryAfterMs": 12000 }
}codeer HTTP-nivåfeilen, for eksempelUNAUTHORIZED,FORBIDDEN,NOT_FOUND,BAD_REQUESTellerTOO_MANY_REQUESTS.data.reason, når til stede, er en mer presis maskinlesbar årsak somauth.key_not_foundellerrate_limit.exceeded. Forgrening baseres på denne i stedet for påmessage, som er for mennesker og kan endre seg.definedertruenår operasjonen lister den feilen i API-referansen, ogfalsefor feil enhver forespørsel kan møte (autentisering, ratelimiter, en ukjent rute).- Et valideringsproblem svarer med
BAD_REQUESTmed problemene idata.formErrorsogdata.fieldErrors.
Hvert svar inneholder også en X-Request-ID. Oppgi den når du kontakter
support, så kan vi finne akkurat den forespørselen.
| Status | Kode | Hva du skal gjøre |
|---|---|---|
400 | BAD_REQUEST | Rett forespørselen; data.fieldErrors navngir feltene |
401 | UNAUTHORIZED | Send en gyldig nøkkel eller sesjon |
403 | FORBIDDEN | Nøkkelen mangler scopet eller rollen operasjonen trenger |
404 | NOT_FOUND | Ressursen finnes ikke, eller du har ikke tilgang til å se den |
409 | CONFLICT | En duplikat skriving er fortsatt under behandling; prøv igjen om kort tid |
413 | PAYLOAD_TOO_LARGE | Forespørselsteksten er over 1 MB; del en bulk-push i mindre batcher |
422 | UNPROCESSABLE_CONTENT | Forespørselen er velformet, men kan ikke utføres |
429 | TOO_MANY_REQUESTS | Vent i Retry-After, så prøv igjen |
Hvert svar oppgir grensen det ble telt mot, i to former:
X-RateLimit-*-headerne;- de IETF-strukturerte feltene
RateLimit(live-tilstand:rer gjenværende forespørsler,tsekunder til vinduet nullstilles) ogRateLimit-Policy(kvoten:qer grensen,wvinduet i sekunder).
Et 429 inneholder også Retry-After i sekunder og data.retryAfterMs. Vent minst så lenge
før neste forespørsel; å prøve igjen tidligere telles og avslås på nytt.
En skriveoperasjon som lister en Idempotency-Key-header i
API-referansen kan prøves på nytt uten å utføre arbeidet to ganger. Send
én nøkkel per logisk skriving og gjenta samme nøkkel ved hvert omforsøk:
- samme nøkkel med samme kropp innen 24 timer spiller av det lagrede svaret;
- samme nøkkel med ulik kropp avslås med
422; - et duplikat som ankommer mens den første fortsatt kjører får
409.
En operasjon uten headeren er ikke idempotent, så prøv den bare på nytt når du vet at det første forsøket ikke ble gjennomført.