Foutcodes

Hieronder vindt u een lijst met REST API-foutcodes en een uitleg van de manier waarop fouten worden geretourneerd naar toepassingen.

Uitzonderingen voor afhandeling en registratie

Wanneer het ontwikkelen voor Marketo, is het belangrijk dat de verzoeken en de reacties het programma worden geopend wanneer een onverwachte uitzondering wordt ontmoet. Terwijl bepaalde soorten uitzonderingen, zoals verlopen authentificatie, veilig door re-authentificatie kunnen worden behandeld, kunnen anderen steuninteractie vereisen, en de verzoeken en de reacties zullen altijd in dit scenario worden gevraagd.

Fouttypen

De Marketo REST-API kan drie verschillende fouttypen retourneren onder normale werking:

Voor fouttypen op antwoordniveau en op recordniveau wordt een HTTP-statuscode van 200 geretourneerd. Voor alle fouttypen moet de HTTP-redenuitdrukking niet worden geëvalueerd omdat deze optioneel is en kan worden gewijzigd.

Fouten op HTTP-niveau

Onder normale bedrijfsomstandigheden mag Marketo slechts twee fouten in de HTTP-statuscode 413 Request Entity Too Large en 414 Request URI Too Long retourneren. Deze zijn zowel terugwinbaar door de fout te vangen, het verzoek te wijzigen en opnieuw te proberen, maar met slimme codeerpraktijken, zou u deze nooit in het wild moeten ontmoeten.

Marketo retourneert 413 als de Request Payload groter is dan 1 MB, of 10 MB in het geval van Import Lead. In de meeste gevallen is het onwaarschijnlijk dat deze limieten worden overschreden, maar door een controle toe te voegen aan de grootte van het verzoek en records te verplaatsen die ertoe leiden dat de limiet wordt overschreden naar een nieuw verzoek, moeten omstandigheden worden voorkomen die ertoe leiden dat deze fout door eindpunten wordt geretourneerd.

414 wordt geretourneerd wanneer de URI van een GET-aanvraag groter is dan 8 kB. Om het te vermijden, controleer tegen de lengte van uw vraagkoord om te zien of overschrijdt het deze grens. Als het uw verzoek in een methode van de POST verandert, dan voer uw vraagkoord als verzoeklichaam met de extra parameter _method=GET in. Hiermee wordt de beperking op URI's genegeerd. Het is zeldzaam om deze grens in de meeste gevallen te raken, maar het is enigszins gemeenschappelijk wanneer het terugwinnen van grote partijen verslagen met lange individuele filterwaarden zoals een GUID.
Het eindpunt van de Identiteitkan een 401 Onbevoegde fout terugkeren. Dit is doorgaans het gevolg van een ongeldige client-id of een ongeldig clientgeheim. Foutcodes op HTTP-niveau

Fouten op responsniveau

Er zijn fouten in het responsniveau aanwezig wanneer de parameter success van de reactie is ingesteld op false en als volgt is gestructureerd:

{
    "requestId": "e42b#14272d07d78",
    "success": false,
    "errors": [
        {
            "code": "601",
            "message": "Unauthorized"
        }
    ]
}

Elk object in de array 'errors' heeft twee leden, code . Dit is een geheel getal tussen 601 en 799 en een message dat de reden voor de fout in normale tekst aangeeft. 6xx-codes geven altijd aan dat een aanvraag volledig is mislukt en niet is uitgevoerd. Een voorbeeld is 601, het "teken van de Toegang ongeldig,"dat kan terugkrijgen door het nieuwe toegangstoken met het verzoek opnieuw voor authentiek te verklaren en over te gaan. 7xx fouten wijzen erop dat het verzoek ontbrak, of omdat geen gegevens werden teruggekeerd, of het verzoek verkeerd geparametereerd was, zoals het omvatten van een ongeldige datum, of het missen van een vereiste parameter.

Foutcodes op responsniveau

Een API-aanroep die deze responscode retourneert, wordt niet in mindering gebracht op uw dagelijkse quotum of uw tarieflimiet.

Recordniveau record_level_errors

Fouten op recordniveau geven aan dat een bewerking niet kan worden voltooid voor een afzonderlijke record, maar dat het verzoek zelf geldig was. Een reactie met fouten op recordniveau volgt dit patroon:

Antwoord

{
   "requestId":"e42b#14272d07d78",
   "success":true,
   "result":[
      {
         "id":50,
         "status":"created"
      },
      {
         "id":51,
         "status":"created"
      },
      {
         "status":"skipped",
         "reasons":[
            {
               "code":"1005",
               "message":"Lead already exists"
            }
         ]
      }
   ]
}

Records die zijn opgenomen in de resultaatarray van aanroepen worden op dezelfde manier geordend als de invoerarray van een aanvraag.
Elke record in een succesvol verzoek kan slagen of ontbreken op een individuele basis, die door het statusgebied van elk verslag inbegrepen in de resultaatserie van een reactie wordt vermeld. Het veld status van deze records wordt overgeslagen en er is een array 'reason' aanwezig. Elke reden bevat een "code"lid, en een "bericht"lid. De code is altijd 1xxx, en het bericht wijst erop waarom het verslag werd overgeslagen. In een voorbeeld zou een 'handeling' in een 'handeling' van een 'Leads synchroniseren' zijn ingesteld op 'AlleenMaken', maar er bestaat al een lead voor een van de sleutels in de verzonden records. Deze kwestie keert een code van 1005 terug, en een bericht van "Lood bestaat reeds"zoals hierboven getoond.

Foutcodes op recordniveau