Guide de l’API Identity Service
Adobe Experience Platform Identity Service gère l’identification de vos clients sur plusieurs appareils, sur plusieurs canaux et quasiment en temps réel dans ce qu’on appelle un graphique d’identités dans Adobe Experience Platform.
Prise en main
Ce guide nécessite une compréhension professionnelle des composants suivants d’Adobe Experience Platform :
- Identity Service: résout le problème fondamental posé par la fragmentation des données de profil client. Pour ce faire, il associe les identités entre les appareils et les systèmes sur lesquels les clients interagissent avec votre marque.
- Real-Time Customer Profile: fournit un profil client en temps réel unifié basé sur des données agrégées provenant de plusieurs sources.
- Experience Data Model (XDM) : cadre normalisé selon lequel Platform organise les données de l’expérience client.
Les sections suivantes contiennent des informations supplémentaires que vous devrez connaître ou dont vous devrez disposer pour passer avec succès des appels à la fonction Identity Service API.
Lecture d’exemples d’appels API
Ce guide fournit des exemples d’appels API pour démontrer comment formater vos requêtes. Il s’agit notamment de chemins d’accès, d’en-têtes requis et de payloads de requêtes correctement formatés. L’exemple JSON renvoyé dans les réponses de l’API est également fourni. Pour plus d’informations sur les conventions utilisées dans la documentation pour les exemples d’appels d’API, voir la section concernant la lecture d’exemples d’appels d’API dans le guide de dépannage Experience Platform.
Collecte des valeurs des en-têtes requis
Pour lancer des appels aux API Platform, vous devez d’abord suivre le tutoriel d’authentification. Le tutoriel d’authentification fournit les valeurs de chacun des en-têtes requis dans tous les appels d’API Experience Platform, comme indiqué ci-dessous :
- Authorization: Bearer
{ACCESS_TOKEN} - x-api-key :
{API_KEY} - x-gw-ims-org-id :
{ORG_ID}
Dans Experience Platform, toutes les ressources sont isolées dans des sandbox virtuels spécifiques. Toutes les requêtes envoyées aux API Platform nécessitent un en-tête spécifiant le nom du sandbox dans lequel l’opération sera effectuée :
- x-sandbox-name :
{SANDBOX_NAME}
Toutes les requêtes contenant un payload (POST, PUT, PATCH) requièrent un en-tête supplémentaire :
- Content-Type: application/json
Acheminement basé sur la région
La variable Identity Service L’API utilise des points de terminaison spécifiques à une région qui nécessitent l’inclusion d’un {REGION} dans le chemin d’accès de la requête. Pendant la mise en service de votre organisation, une région est déterminée et stockée dans votre profil d’organisation. L’utilisation de la région appropriée avec chaque point de terminaison garantit que toutes les requêtes effectuées à l’aide de la variable Identity Service Les API sont acheminées vers la région appropriée.
Deux régions sont actuellement prises en charge par Identity Service API : VA7 et NLD2.
Le tableau ci-dessous présente des exemples de chemins qui utilisent les régions :
Si vous ne parvenez pas à localiser la région dans votre profil d’entreprise, contactez votre administrateur système pour obtenir de l’aide.
En utilisant la variable Identity Service API
Les paramètres d’identité utilisés dans ces services peuvent être exprimés de l’une des deux manières suivantes : composite ou XID.
Les identités composites sont des éléments incluant à la fois la valeur d’identifiant et l’espace de noms. Lors de l’utilisation d’identités composites, l’espace de noms peut être fourni soit par nom (namespace.code), soit par identifiant (namespace.id).
Lorsqu’une identité est conservée, Identity Service génère et affecte un identifiant à cette identité, appelé identifiant natif, ou XID. Toutes les variations des API de cluster et de mappage prennent en charge les identités composites et les XID dans leurs requêtes et leurs réponses. L’un des paramètres est requis pour utiliser ces API : xid ou une combinaison de [ns ou nsid] et id.
Pour limiter le payload dans les réponses, les API adaptent leurs réponses au type de construction d’identité utilisée. En d’autres termes, si vous transmettez un XID, vos réponses auront des XID, si vous transmettez des identités composites, la réponse suivra la structure utilisée dans la requête.
Les exemples de ce document ne couvrent pas toutes les fonctionnalités de la fonction Identity Service API. Pour l’API complète, voir le guide de référence de l’API Swagger.
Étapes suivantes
Maintenant que vous avez collecté les informations d’identification requises, vous pouvez passer au reste du guide de développement. Chaque section fournit des informations importantes sur les points d’entrée et inclut des exemples d’appels API pour effectuer des opérations CRUD. Chaque appel comprend le format général de l’API, un exemple de requête montrant les en-têtes requis et les payloads correctement formatés, ainsi qu’un exemple de réponse pour un appel réussi.