Codes d’erreur

Vous trouverez ci-dessous des listes de codes d’erreur de l’API REST et 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 est rencontrée. Bien que certains types d’exceptions, comme 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. Les demandes et réponses seront toujours demandées dans ce scénario.

Types d’erreurs

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

Pour les types d’erreur de niveau réponse et de niveau enregistrement, un code d’état HTTP de 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 peut être modifiée.

Erreurs au niveau du HTTP

Dans des circonstances de fonctionnement normales, Marketo ne doit renvoyer que deux erreurs de code d’état HTTP, 413 Request Entity Too Large et 414 Request URI Too Long. Vous pouvez les récupérer en interceptant l’erreur, en modifiant la requête et en réessayant. Toutefois, avec les pratiques de codage intelligent, vous ne devriez jamais les rencontrer en mode sauvage.

Marketo renvoie la valeur 413 si la payload de la requête dépasse 1 Mo, ou 10 Mo dans le cas du lead d’importation. Dans la plupart des scénarios, il est peu probable que ces limites soient atteintes, mais l’ajout d’une vérification à la taille de la requête et le déplacement de tous les enregistrements, qui entraînent le dépassement de la limite dans une nouvelle requête, doivent éviter toute circonstance qui entraîne le renvoi de cette erreur par n’importe quel point d’entrée.

L’erreur 414 est renvoyée lorsque l’URI d’une requête 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 remplace votre requête par une méthode POST, saisissez votre chaîne de requête comme corps de la 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 assez courant lors de la récupération de lots volumineux d'enregistrements avec de longues valeurs de filtre individuel, comme un GUID.
Le point d’entrée Identity peut renvoyer une erreur 401 Non autorisé. Cela est généralement dû à un ID client non valide ou à un secret client non valide. Codes d’erreur au niveau HTTP

Erreurs de niveau de réponse

Les erreurs de niveau de réponse sont présentes lorsque le paramètre success de la réponse est défini sur false et sont structurées 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 guillemets compris entre 601 et 799 et un message donnant 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. Exemple : un 601, « Jeton d’accès non valide », qui peut être récupéré en s’authentifiant à nouveau 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é paramétrée de manière incorrecte, par exemple en incluant une date non valide, ou en raison d’un paramètre obligatoire manquant.

Codes d’erreur au niveau de la 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 que la demande elle-même était valide. Une réponse contenant des erreurs au niveau des enregistrements 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 trié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 sur une base individuelle, ce qui est indiqué par le champ de statut de chaque enregistrement inclus dans le tableau de résultats d’une réponse. Le champ « statut » de ces enregistrements sera « ignoré » et un tableau « raisons » sera 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, si une demande de leads de synchronisation a « action » défini sur « createOnly », mais qu’un lead 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