Présentation de l’API d’administration Target

Cet article présente les informations générales nécessaires pour comprendre et utiliser les Adobe Target Admin API avec succès. Le contenu suivant suppose que vous comprenez comment configurer l’authentification pour les Adobe Target Admin API .

Avant de commencer

Dans tous les exemples de code fournis pour les API d’administration, remplacez {tenant} par votre valeur client, your-bearer-token par le jeton d’accès que vous générez avec votre JWT et your-api-key par votre clé 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 Target d’Adobe.

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 une 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 concernant 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"
        }
    ]
}

Admin Postman Collection

Postman est une application qui facilite le déclenchement des appels API. Cette collection Postman de l’API Target Admin contient tous les appels de l’API Target Admin 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 Target Admin.

Activités

Une activité vous permet de tester ou de personnaliser du contenu pour vos utilisateurs et utilisatrices. 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 par lots unique.

Exécuter les appels par lots

POST /{tenant}/target/batch

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

Le traitement par lots 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 par lot prend en charge 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 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 POST et PUT). L’API Batch 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 facultatifs et un corps facultatif (qui est une chaîne codée JSON). Pour effectuer des requêtes par lots, créez un objet JSON qui décrit chaque opération individuelle à effectuer. Le nombre maximal d’opérations autorisées est de 256 (de 0 à 255).

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

Souvent, les opérations de la requête sont dépendantes ; par exemple, la sortie d’une opération peut être utilisée en 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.

Pour lier deux opérations par lots, spécifiez dans l’opération dépendante l’identifiant de l’opération requise, par exemple : « dependanceOnOperationId » : 5. En outre, les identifiants des ressources créées via des requêtes POST d’opérations par lots peuvent être utilisés dans des opérations dépendantes dans « relativeUrl » et « body ».

Autorisations et limitation

Pour exécuter des actions d’API par lot, l’utilisateur sous-jacent doit au moins disposer des droits d’« éditeur » (pour chaque opération individuelle, si des droits supplémentaires sont requis, et non l’utilisateur lui-même, l’opération individuelle échoue). Les stratégies de limitation habituelles sont appliquées aux actions de l’API par lots comme si chaque opération avait été effectuée individuellement.

Le traitement par lots se termine lorsque toutes les opérations sont terminées, une opération peut être réussie (code d’état 2xx), en échec (code d’état 4xx, 5xx) ou ignorée, car une opération de dépendance a échoué ou a été ignorée.

Paramètres d'objet de demande

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 de l’objet de réponse

Exemple d’objet de réponse

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