Felkoder
Nedan finns listor över felkoder för REST API och en förklaring av hur fel returneras till programmen.
Hantera och logga undantag
När du utvecklar för Marketo är det viktigt att begäranden och svar loggas när ett oväntat undantag inträffar. Vissa typer av undantag, till exempel autentisering som har upphört att gälla, kan hanteras säkert genom återautentisering, men andra kan kräva supportinteraktioner, och begäranden och svar kommer alltid att begäras i det här scenariot.
Feltyper
Marketo REST API kan returnera tre olika typer av fel vid normal användning:
- HTTP-nivå: Dessa fel indikeras av en
4xx
-kod. - Svarsnivå: Dessa fel ingår i arrayen "errors" i JSON-svaret.
- Postnivå: Dessa fel ingår i arrayen "result" i JSON-svaret och anges på individuell postbasis med arrayen "status" och "reasons".
För feltyperna Svarsnivå och Postnivå returneras HTTP-statuskoden 200. För alla feltyper ska HTTP-orsaksfrasen inte utvärderas eftersom den är valfri och kan ändras.
HTTP-nivåfel
Under normala driftförhållanden bör Marketo endast returnera två HTTP-statuskodfel, 413 Request Entity Too Large
och 414 Request URI Too Long
. Båda kan återställas genom att felet identifieras, begäran ändras och nya försök görs, men med smart kodning bör du aldrig stöta på detta i verkligheten.
Marketo returnerar 413 om nyttolasten för begäran överstiger 1 MB, eller 10 MB vid import av lead. I de flesta fall är det osannolikt att de här gränserna kommer att nås, men om man lägger till en kontroll av begärans storlek och flyttar poster, vilket gör att gränsen överskrids för en ny begäran, bör det inte finnas några omständigheter som kan leda till att felet returneras av någon slutpunkt.
414 returneras när URI:n för en GET-begäran överstiger 8 kB. För att undvika det bör du kontrollera mot längden på frågesträngen för att se om den överskrider den här gränsen. Om den ändrar din begäran till en POST-metod anger du frågesträngen som begärandebrödtext med den extra parametern _method=GET
. Detta innebär att begränsningen för URI:er ignoreras. I de flesta fall är det ovanligt att den här gränsen nås, men det är något vanligt när du hämtar stora grupper med poster med långa enskilda filtervärden som GUID.
Identity-slutpunkten kan returnera ett 401 otillåtet fel. Detta beror vanligtvis på ett ogiltigt klient-ID eller ogiltig klienthemlighet. Felkoder på HTTP-nivå
Fel på svarsnivå
Svarsnivåfel förekommer när parametern success
i svaret är inställd på false och är strukturerade på följande sätt:
{
"requestId": "e42b#14272d07d78",
"success": false,
"errors": [
{
"code": "601",
"message": "Unauthorized"
}
]
}
Varje objekt i arrayen "errors" har två medlemmar, code
, som är ett heltal med citattecken mellan 601 och 799, och en message
som anger varför felet beror på texten. 6xx-koder anger alltid att en begäran misslyckades helt och inte kördes. Ett exempel är 601, "Åtkomsttoken invalid", som kan återställas genom återautentisering och genom att skicka den nya åtkomsttoken med begäran. 7xx-fel indikerar att begäran misslyckades, antingen på grund av att inga data returnerades, eller på grund av att begäran parametriserades felaktigt, till exempel att ett ogiltigt datum inkluderades, eller att en obligatorisk parameter saknades.
Felkoder på svarsnivå
Ett API-anrop som returnerar den här svarskoden räknas inte av mot din dagliga kvot eller din avgiftsgräns.
- Ett datum som inte hade rätt format angavs
- Ett ogiltigt ID för dynamiskt innehåll angavs
Anropet kan inte utföras eftersom det bryter mot ett krav på att skapa eller uppdatera en resurs, till exempel att försöka skapa ett e-postmeddelande utan en mall. Det går också att få följande fel när du försöker:
- Hämta innehåll för landningssidor som innehåller socialt innehåll.
- Klona ett program som innehåller vissa resurstyper (mer information finns i Programklon).
- Godkänn en tillgång som inte har något utkast (det vill säga som redan har godkänts).
Postnivå record_level_errors
Postnivåfel indikerar att en åtgärd inte kunde slutföras för en enskild post, men själva begäran var giltig. Ett svar med fel på postnivå följer det här mönstret:
Svar
{
"requestId":"e42b#14272d07d78",
"success":true,
"result":[
{
"id":50,
"status":"created"
},
{
"id":51,
"status":"created"
},
{
"status":"skipped",
"reasons":[
{
"code":"1005",
"message":"Lead already exists"
}
]
}
]
}
Poster som ingår i den resulterande arrayen med anrop ordnas på samma sätt som indataarrayen för en begäran.
Varje post i en lyckad begäran kan lyckas eller misslyckas på individnivå, vilket anges av statusfältet för varje post som ingår i resultatarrayen i ett svar. Fältet "status" för de här posterna hoppas över och arrayen "reasons" finns. Varje orsak innehåller en"kodmedlem" och en"meddelandemedlem". Koden är alltid 1xxx och meddelandet anger varför posten hoppades över. Ett exempel är när en begäran om synkronisering av leads har "action" inställt på "createOnly", men det redan finns en lead för en av nycklarna i de skickade posterna. I det här fallet returneras koden 1005 och meddelandet"Lead already exists" (Lead finns redan) visas ovan.