Fel och begränsningar för anrop
Det enda felmeddelande som varje misslyckad förfrågan returnerar, gränshuvudena för anrop, och hur du säkert försöker igen med en skrivning.
Varje slutpunkt misslyckas på samma sätt, så en klient hanterar fel, hastighetsbegränsningar och omsändningar en gång och återanvänder den koden överallt, inklusive över MCP.
Varje icke-2xx-svar är ett JSON-objekt:
{
"defined": false,
"code": "TOO_MANY_REQUESTS",
"message": "Too many requests",
"data": { "reason": "rate_limit.exceeded", "retryAfterMs": 12000 }
}codeär HTTP-nivåfelet, till exempelUNAUTHORIZED,FORBIDDEN,NOT_FOUND,BAD_REQUESTellerTOO_MANY_REQUESTS.data.reason, när det finns, är en mer detaljerad maskinläsbar orsak somauth.key_not_foundellerrate_limit.exceeded. Grena på det i stället för påmessage, som är för människor och kan ändras.definedärtruenär operationen listar det felet i API-referensen, ochfalseför fel som alla förfrågningar kan möta (autentisering, hastighetsbegränsningar, en okänd rutt).- Ett valideringsfel svarar
BAD_REQUESTmed problemen idata.formErrorsochdata.fieldErrors.
Varje svar innehåller också ett X-Request-ID. Ange det när du kontaktar
support, så kan vi hitta exakt den förfrågan.
| Status | Kod | Vad du ska göra |
|---|---|---|
400 | BAD_REQUEST | Åtgärda förfrågan; data.fieldErrors namnger fälten |
401 | UNAUTHORIZED | Skicka en giltig nyckel eller session |
403 | FORBIDDEN | Nyckeln saknar det omfång eller den roll som operationen kräver |
404 | NOT_FOUND | Resursen finns inte, eller så har du inte behörighet att se den |
409 | CONFLICT | En duplicerad skrivning är fortfarande pågående; försök igen om en stund |
413 | PAYLOAD_TOO_LARGE | Förfrågningskroppen är över 1 MB; dela upp en bulkpush i mindre batcher |
422 | UNPROCESSABLE_CONTENT | Förfrågan är välformulerad men kan inte tillämpas |
429 | TOO_MANY_REQUESTS | Vänta i Retry-After, sedan försöker du igen |
Varje svar anger den gräns som den räknades mot, i två former:
X-RateLimit-*-huvudena;- de IETF-strukturerade fälten
RateLimit(aktuellt tillstånd:rär de återstående förfrågningarna,tsekunderna tills fönstret återställs) ochRateLimit-Policy(kvoten:qär gränsen,wfönstret i sekunder).
Ett 429 innehåller också Retry-After i sekunder och data.retryAfterMs. Vänta minst så länge innan nästa förfrågan; att försöka tidigare räknas och nekas igen.
En skrivoperation som listar en Idempotency-Key-huvud i
API-referensen kan omsändas utan att arbetet utförs två gånger. Skicka en nyckel per logisk skrivning och upprepa samma nyckel vid varje omsändning:
- samma nyckel med samma kropp inom 24 timmar spelar upp det lagrade svaret;
- samma nyckel med en annan kropp nekas med
422; - en duplicering som anländer medan den första fortfarande körs får
409.
En operation utan huvudet är inte idempotent, så omsänd den bara när du vet att det första försöket inte landade.