Présentation de l’API d’administration de Target

Cet article présente un aperçu des informations générales nécessaires pour comprendre et utiliser correctement les Adobe Target Admin APIs. Le contenu suivant suppose que vous comprenez comment configurer l’authentification pour les Adobe Target Admin APIs.

Avant de commencer

Dans tous les exemples de code fournis pour les API d'administration, remplacez {tenant} par la valeur de votre client, your-bearer-token par le jeton d'accès que vous générez avec vos JWT et your-api-key avec votre clé d'API provenant de Adobe Developer Console. Pour plus d’informations sur les clients et les JWT, consultez l’article sur la configuration de l’authentification pour les API d’administration d’Adobe Target.

Contrôle de version

Toutes les API sont associées à une version. Il est important de fournir la version appropriée de l’API que vous souhaitez utiliser.

Si la requête contient un payload (POST ou PUT), l’en-tête Content-Type de la requête est utilisé pour spécifier la version.

Si la requête ne contient pas de payload (GET, DELETE ou OPTIONS), l’en-tête Accept est utilisé pour spécifier la version.

Si aucune version n’est fournie, l’appel est défini par défaut sur V1 (application/vnd.adobe.target.v1+json).

Message d’erreur pour les fonctionnalités non prises en charge

{
    "httpStatus": 406,
    "requestId": "8752b736-cf71-4d81-86c3-94be2b5ae648",
    "requestTime": "2018-02-02T21:39:06.405Z",
    "errors": [
        {
            "errorCode": "Unsupported.Feature",
            "message": "Unsupported features detected"
        }
    ]
}

Collecte Postman d’administration

Postman est une application qui permet de déclencher facilement des appels API. Cette collection Postman de l’API d’administration Targetcontient tous les appels de l’API d’administration Target qui nécessitent une authentification à l’aide des activités, audiences, offres, rapports, mbox et environnements.

Codes de réponse

Voici les codes de réponse courants pour les API d’administration Target.

Activités

Une activité vous permet de tester ou de personnaliser du contenu pour vos utilisateurs. Les activités peuvent être de l’un des types suivants :

Mises à jour par lots

Plusieurs API d’administration peuvent être exécutées en tant que requête de lot unique.

Exécution des appels par lot

POST /{tenant}/target/batch

Empilez plusieurs appels d’API ensemble et exécutez-les dans un seul lot.

Le traitement par lot vous permet de transmettre des instructions pour plusieurs opérations dans une seule requête HTTP. Vous pouvez également spécifier des dépendances entre les opérations associées (décrites dans une section ci-dessous). TNT traitera chacune de vos opérations indépendantes (éventuellement en parallèle) et traitera vos opérations dépendantes de manière séquentielle. Une fois toutes les opérations terminées, une réponse consolidée est renvoyée et la connexion HTTP est fermée.

L’API de lot accepte un tableau de requêtes HTTP logiques représentées sous la forme de tableaux JSON : chaque requête comporte une méthode (correspondant à la méthode HTTP GET/PUT/POST/DELETE, etc.), une valeur relativeUrl (la partie de l’URL après admin/rest/), un tableau d’en-têtes facultatifs (correspondant aux en-têtes HTTP) et un corps facultatif (pour les requêtes de POST et de PUT). L’API de lot renvoie un tableau de réponses HTTP logiques représentées sous la forme de tableaux JSON : chaque réponse comporte un code d’état, un tableau d’en-têtes facultatif et un corps facultatif (qui est une chaîne codée au format JSON). Pour effectuer des requêtes par lot, créez un objet JSON qui décrit chaque opération à effectuer. Le nombre maximal d’opérations autorisées est de 256 (de 0 à 255).

Spécification des dépendances entre les opérations dans la requête Par défaut, les opérations spécifiées dans la requête de l’API de lot sont indépendantes : elles peuvent être exécutées dans un ordre arbitraire sur le serveur et une erreur dans une opération n’a aucune incidence sur l’exécution d’autres opérations.

Souvent, les opérations de la requête dépendent ; par exemple, la sortie d’une opération peut être utilisée dans l’entrée de l’opération suivante. Par exemple, l’offre créée dans operationId=0 doit être utilisée dans operationId=1 de création de campagne.

Afin de lier deux opérations par lots ensemble, spécifiez dans l’opération dépendante l’identifiant de l’opération requise, par exemple : "dépendOnOperationId" : 5. En outre, les identifiants des ressources créées via les demandes POST d’opérations par lots peuvent être utilisés dans des opérations dépendantes à la fois dans "relativeUrl" et "body".

Autorisations et limitation

Pour exécuter des actions d’API par lot, l’utilisateur sous-jacent doit disposer au moins des droits "d’éditeur" (pour chaque opération individuelle, au cas où des droits supplémentaires seraient requis par rapport à l’utilisateur, l’opération individuelle échouera). Les stratégies de ralentissement classiques sont appliquées aux actions de l’API de lot comme si chaque opération avait été effectuée individuellement.

Le traitement par lots se termine une fois toutes les opérations terminées, une opération peut être une réussite (2xx statusCode), un échec (4xx, 5xx status code) ou une saut en raison d’un échec ou d’une saut d’une opération de dépendance.

Paramètres de l’objet de requête

Exemple d’objet de requête

{
  "operations": [
    {
      "operationId": 1,
      "dependsOnOperationIds~": [0],
      "method": "POST",
      "relativeUrl": "/v1/offers",
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "body~": {
        "key": "value"
      }
    }
  ]
}

Paramètres d’objet de réponse

Exemple d’objet Response

{
  "results": [
    {
      "operationId": 1,
      "skipped~": false,
      "statusCode~": 200,
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json; charset=UTF-8"
        }
      ],
      "body~": {
        "id": 5
      }
    }
  ]
}