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:

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.

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.

Felkoder på postnivå