Fehler-Codes

Im Folgenden finden Sie eine Liste der REST-API-Fehler-Codes und eine Erläuterung, wie Fehler an Programme zurückgegeben werden.

Behandeln und Protokollieren von Ausnahmen

Bei der Entwicklung für Marketo ist es wichtig, dass Anfragen und Antworten protokolliert werden, wenn eine unerwartete Ausnahme auftritt. Während bestimmte Arten von Ausnahmen, z. B. abgelaufene Authentifizierungen, sicher durch erneute Authentifizierung verarbeitet werden können, erfordern andere möglicherweise Support-Interaktionen, und Anfragen und Antworten werden immer in diesem Szenario angefordert.

Fehlertypen

Die Marketo-REST-API kann im Normalbetrieb drei verschiedene Fehlertypen zurückgeben:

Bei Fehlertypen auf Antwort- und Datensatz-Ebene wird ein HTTP-Status-Code von 200 zurückgegeben. Für alle Fehlertypen sollte die HTTP-Ursachenphrase nicht ausgewertet werden, da sie optional ist und sich ändern kann.

Fehler auf HTTP-Ebene

Unter normalen Betriebsbedingungen sollte Marketo nur zwei HTTP-Status-Code-Fehler, 413 Request Entity Too Large und 414 Request URI Too Long, zurückgeben. Beide können durch Abrufen des Fehlers, Ändern der Anfrage und erneutes Versuchen wiederhergestellt werden. Mit intelligenten Kodierungsverfahren sollten Sie jedoch nie auf diese stoßen.

Marketo gibt 413 zurück, wenn die Payload der Anfrage 1 MB überschreitet, oder 10 MB im Fall des Leadimports. In den meisten Szenarien ist es unwahrscheinlich, dass diese Beschränkungen erreicht werden. Durch Hinzufügen einer Prüfung der Größe der Anfrage und Verschieben von Datensätzen, die dazu führen, dass das Limit überschritten wird, zu einer neuen Anfrage sollten jedoch alle Umstände verhindert werden, die zu diesem Fehler bei Endpunkten führen.

414 wird zurückgegeben, wenn der URI einer GET-Anfrage 8 KB überschreitet. Um dies zu vermeiden, überprüfen Sie die Länge Ihrer Abfragezeichenfolge, um festzustellen, ob sie diesen Grenzwert überschreitet. Wenn Ihre Anfrage jedoch in eine POST-Methode geändert wird, geben Sie Ihre Abfragezeichenfolge als Anfragetext mit dem zusätzlichen Parameter _method=GET ein. Dadurch wird die Einschränkung für URIs aufgegeben. In den meisten Fällen ist es selten, dieses Limit zu erreichen, aber es ist etwas üblich, wenn große Batches von Datensätzen mit langen individuellen Filterwerten wie einer GUID abgerufen werden.
Der Identity-Endpunkt kann einen 401-Fehler „Nicht autorisiert“ zurückgeben. Dies ist normalerweise auf eine ungültige Client-ID oder ein ungültiges Client-Geheimnis zurückzuführen. Fehlercodes auf HTTP-Ebene

Fehler auf Antwortebene

Fehler auf Antwortebene sind vorhanden, wenn der success der Antwort auf „false“ gesetzt ist. Sie sind wie folgt strukturiert:

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

Jedes Objekt im Array „errors“ hat zwei Mitglieder, code, was einer angegebenen Ganzzahl von 601 bis 799 entspricht, und einen message, der den Klartext-Grund für den Fehler angibt. 6xx-Codes zeigen immer an, dass eine Anfrage vollständig fehlgeschlagen ist und nicht ausgeführt wurde. Ein Beispiel ist ein 601-Zugriffstoken „Ungültig“, das durch erneute Authentifizierung und Übergabe des neuen Zugriffstokens mit der Anfrage wiederhergestellt werden kann. 7xx-Fehler zeigen an, dass die Anfrage fehlgeschlagen ist, entweder weil keine Daten zurückgegeben wurden oder weil die Anfrage falsch parametrisiert wurde, z. B. weil ein ungültiges Datum enthalten war oder ein erforderlicher Parameter fehlte.

Fehlercodes auf Antwortebene

Ein API-Aufruf, der diesen Antwort-Code zurückgibt, wird nicht auf Ihr tägliches Kontingent oder Ihr Ratenlimit angerechnet.

auf Rekordebene record_level_errors

Fehler auf Datensatzebene zeigen an, dass ein Vorgang für einen einzelnen Datensatz nicht abgeschlossen werden konnte, die Anfrage selbst jedoch gültig war. Eine Antwort mit Fehlern auf Datensatzebene folgt diesem Muster:

Antwort

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

Datensätze, die im Ergebnis-Array von Aufrufen enthalten sind, werden auf die gleiche Weise sortiert wie das Eingabe-Array einer Anfrage.
Jeder Datensatz in einer erfolgreichen Anfrage kann auf individueller Basis erfolgreich sein oder fehlschlagen. Dies wird durch das Statusfeld jedes Datensatzes angezeigt, der im Ergebnis-Array einer Antwort enthalten ist. Das Feld „Status“ dieser Datensätze wird „übersprungen“ und ein Array „Gründe“ ist vorhanden. Jeder Grund enthält ein Element des Typs „Code“ und ein Element des Typs „Nachricht“. Der Code ist immer 1xxx. Die Meldung gibt an, warum der Datensatz übersprungen wurde. Ein Beispiel wäre, wenn bei einer Anfrage zum Synchronisieren von Leads „Aktion“ auf „createOnly“ gesetzt ist, aber für einen der Schlüssel in den gesendeten Datensätzen bereits ein Lead vorhanden ist. In diesem Fall wird der Code 1005 zurückgegeben und die Meldung „Lead existiert bereits“ wird wie oben angezeigt angezeigt.

Fehlercodes auf Datensatzebene