Nordvec Docs

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.

Den här guiden har maskinöversatts från det engelska originalet och har inte granskats av en person. Den engelska versionen är giltig. Översättning: AI‑bearbetning i Frankrike. Läs det engelska originalet
  • Visa som Markdown
  • Visa kontextpaket

Externa assistenter

Dessa öppnar en tredjeparts-AI-tjänst utanför EU. Länken skickar sidans adress, och allt du frågar om där behandlas av den leverantören enligt deras egna villkor.

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.

Felkuvertet

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 exempel UNAUTHORIZED, FORBIDDEN, NOT_FOUND, BAD_REQUEST eller TOO_MANY_REQUESTS.
  • data.reason, när det finns, är en mer detaljerad maskinläsbar orsak som auth.key_not_found eller rate_limit.exceeded. Grena på det i stället för på message, som är för människor och kan ändras.
  • defined är true när operationen listar det felet i API-referensen, och false för fel som alla förfrågningar kan möta (autentisering, hastighetsbegränsningar, en okänd rutt).
  • Ett valideringsfel svarar BAD_REQUEST med problemen i data.formErrors och data.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.

Vanliga statuskoder

StatusKodVad du ska göra
400BAD_REQUESTÅtgärda förfrågan; data.fieldErrors namnger fälten
401UNAUTHORIZEDSkicka en giltig nyckel eller session
403FORBIDDENNyckeln saknar det omfång eller den roll som operationen kräver
404NOT_FOUNDResursen finns inte, eller så har du inte behörighet att se den
409CONFLICTEn duplicerad skrivning är fortfarande pågående; försök igen om en stund
413PAYLOAD_TOO_LARGEFörfrågningskroppen är över 1 MB; dela upp en bulkpush i mindre batcher
422UNPROCESSABLE_CONTENTFörfrågan är välformulerad men kan inte tillämpas
429TOO_MANY_REQUESTSVänta i Retry-After, sedan försöker du igen

Hastighetsbegränsningar

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, t sekunderna tills fönstret återställs) och RateLimit-Policy (kvoten: q är gränsen, w fö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.

Säker omsändning av skrivningar

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.

Var den här sidan till hjälp?

På den här sidan