Fejl og hastighedsgrænser
Den ene fejlkuvert, som hvert fejlslagent request returnerer, hastighedsgrænse-headers og hvordan du genforsøger en skrivning sikkert.
Hvert endpoint fejler på samme måde, så en klient håndterer fejl, rategrænser og genforsøg én gang og genbruger den kode overalt, herunder over MCP.
Ethvert ikke-2xx-svar er ét JSON-objekt:
{
"defined": false,
"code": "TOO_MANY_REQUESTS",
"message": "Too many requests",
"data": { "reason": "rate_limit.exceeded", "retryAfterMs": 12000 }
}codeer fejlen på HTTP-niveau, for eksempelUNAUTHORIZED,FORBIDDEN,NOT_FOUND,BAD_REQUESTellerTOO_MANY_REQUESTS.data.reason, når den er til stede, er en mere præcis maskinlæsbar årsag somauth.key_not_foundellerrate_limit.exceeded. Forgrén på den i stedet for påmessage, som er til mennesker og kan ændre sig.definedertrue, når operationen oplister den fejl i API-referencen, ogfalsefor fejl, som enhver anmodning kan møde (autentificering, rategrænser, en ukendt rute).- Et valideringsfejl svarer med
BAD_REQUESTog problemerne idata.formErrorsogdata.fieldErrors.
Hvert svar indeholder også et X-Request-ID. Citér det, når du kontakter
support, så kan vi finde den præcise anmodning.
| Status | Kode | Hvad du skal gøre |
|---|---|---|
400 | BAD_REQUEST | Ret anmodningen; data.fieldErrors angiver felterne |
401 | UNAUTHORIZED | Send en gyldig nøgle eller session |
403 | FORBIDDEN | Nøglen mangler det scope eller den rolle, som operationen kræver |
404 | NOT_FOUND | Ressourcen findes ikke, eller du har ikke adgang til at se den |
409 | CONFLICT | En duplikat-skrivning er stadig i gang; prøv igen om kort tid |
413 | PAYLOAD_TOO_LARGE | Anmodningsbrød er over 1 MB; del en bulk-push op i mindre batches |
422 | UNPROCESSABLE_CONTENT | Anmodningen er velformet, men kan ikke anvendes |
429 | TOO_MANY_REQUESTS | Vent i Retry-After, og prøv derefter igen |
Hvert svar angiver den grænse, som det blev talt op imod, i to former:
X-RateLimit-*-headere;- de IETF-strukturerede felter
RateLimit(live-tilstand:rer de resterende anmodninger,ter sekunderne, indtil vinduet nulstilles) ogRateLimit-Policy(kvotaen:qer grænsen,wer vinduet i sekunder).
Et 429 medfører også Retry-After i sekunder og data.retryAfterMs. Vent mindst så længe,
før du sender den næste anmodning; et tidligere genforsøg tælles med og
afvises igen.
En skrivningsoperation, der oplister en Idempotency-Key-header i
API-referencen, kan genafsendes uden at udføre arbejdet to gange. Send
én nøgle per logisk skrivning, og gentag den samme nøgle ved hvert genforsøg:
- den samme nøgle med det samme brød inden for 24 timer afspiller det gemte svar;
- den samme nøgle med et andet brød afvises med
422; - en duplikat, der ankommer, mens den første stadig kører, får
409.
En operation uden headeren er ikke idempotent, så genafsend den kun, når du ved, at det første forsøg ikke blev gennemført.