Codes d’erreur

Vous trouverez ci-dessous des listes de codes d’erreur de l’API REST, ainsi qu’une explication de la manière dont les erreurs sont renvoyées aux applications.

Gestion et journalisation des exceptions

Lors du développement pour Marketo, il est important que les requêtes et les réponses soient consignées lorsqu’une exception inattendue se produit. Bien que certains types d’exceptions, telles que l’authentification expirée, puissent être gérés en toute sécurité par la réauthentification, d’autres peuvent nécessiter des interactions d’assistance, et les demandes et réponses seront toujours demandées dans ce scénario.

Types d’erreur

L’API REST Marketo peut renvoyer trois types d’erreurs différents en cas de fonctionnement normal :

Pour les types d’erreur Response-Level et Record-Level, un code d’état HTTP 200 est renvoyé. Pour tous les types d’erreur, l’expression de raison HTTP ne doit pas être évaluée, car elle est facultative et susceptible d’être modifiée.

Erreurs au niveau HTTP

Dans des circonstances normales d’exploitation, Marketo ne doit renvoyer que deux erreurs de code d’état HTTP, 413 Request Entity Too Large, et 414 Request URI Too Long. Ils peuvent tous deux être récupérés en capturant l’erreur, en modifiant la requête et en réessayant, mais avec des pratiques de codage intelligent, vous ne devriez jamais les rencontrer dans la nature.

Marketo renvoie 413 si la charge utile de la requête dépasse 1 Mo ou 10 Mo dans le cas d’une piste d’importation. Dans la plupart des scénarios, il est peu probable que ces limites soient atteintes, mais l’ajout d’une vérification de la taille de la requête et le déplacement d’enregistrements, ce qui entraîne le dépassement de la limite par une nouvelle requête, devrait empêcher tout contexte, ce qui entraîne le renvoi de cette erreur par les points de terminaison.

414 est renvoyé lorsque l’URI d’une demande de GET dépasse 8 Ko. Pour l’éviter, vérifiez la longueur de votre chaîne de requête pour voir si elle dépasse cette limite. S’il transforme votre requête en méthode de POST, entrez votre chaîne de requête en tant que corps de requête avec le paramètre supplémentaire. _method=GET. Cela annule la limitation des URI. Il est rare d’atteindre cette limite dans la plupart des cas, mais cela est quelque peu courant lors de la récupération de lots volumineux d’enregistrements avec de longues valeurs de filtre individuelles, telles qu’un GUID.
La variable Identité Le point de terminaison peut renvoyer une erreur 401 Non autorisé. Cela est généralement dû à un ID de client non valide ou à un secret de client non valide. Codes d’erreur au niveau HTTP

Erreurs au niveau de la réponse

Des erreurs de niveau de réponse sont présentes lorsque la variable success Le paramètre de la réponse est défini sur false et est structuré comme suit :

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

Chaque objet du tableau "errors" comporte deux membres, code, qui est un entier entre 601 et 799 et un message indiquant la raison en texte brut de l’erreur. Les codes 6xx indiquent toujours qu’une requête a complètement échoué et n’a pas été exécutée. Par exemple, 601, "Jeton d’accès non valide", qui peut être récupéré en réauthentifiant et en transmettant le nouveau jeton d’accès avec la requête. Les erreurs 7xx indiquent que la requête a échoué, soit parce qu’aucune donnée n’a été renvoyée, soit parce que la requête a été mal paramétrée, par exemple en incluant une date non valide, ou parce qu’un paramètre requis a été absent.

Codes d’erreur de niveau réponse

Un appel API qui renvoie ce code de réponse n’est pas comptabilisé dans votre quota quotidien ou votre limite de taux.

Record Level record_level_errors

Les erreurs de niveau enregistrement indiquent qu’une opération n’a pas pu être effectuée pour un enregistrement individuel, mais la requête elle-même était valide. Une réponse avec des erreurs de niveau enregistrement suit ce modèle :

Réponse

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

Les enregistrements inclus dans le tableau de résultats des appels sont classés de la même manière que le tableau d’entrée d’une requête.
Chaque enregistrement d’une requête réussie peut réussir ou échouer individuellement, ce qui est indiqué par le champ d’état de chaque enregistrement inclus dans le tableau de résultat d’une réponse. Le champ "status" de ces enregistrements sera "sauté" et un tableau "raisons" est présent. Chaque raison contient un membre "code" et un membre "message". Le code est toujours 1xxx et le message indique pourquoi l’enregistrement a été ignoré. Par exemple, une requête de pistes de synchronisation avec "action" définie sur "createOnly", mais une piste existe déjà pour l’une des clés dans les enregistrements envoyés. Ce cas renvoie un code de 1005 et un message indiquant "Le prospect existe déjà" comme indiqué ci-dessus.

Codes d’erreur au niveau de l’enregistrement