Sur cette page : connectez-vous à des API REST tierces et configurez l’authentification pour pouvoir extraire des données externes dans vos parcours pour les utiliser dans les conditions et la personnalisation.
Utilisation de sources de données externes gs-ext-data-sources
Les sources de données externes vous permettent de définir une connexion à des systèmes tiers, par exemple, si vous utilisez un système de réservation d’hôtel pour vérifier si la personne a réservé une chambre. Contrairement à la source de données Adobe Experience Platform intégrée, vous pouvez créer autant de sources de données externes que nécessaire.
-
Les mécanismes de sécurisation lors de l’utilisation de systèmes externes sont répertoriés dans cette page.
-
Les réponses étant désormais prises en charge, vous devez utiliser des actions personnalisées au lieu de sources de données pour les cas d’utilisation de sources de données externes. Pour plus d’informations sur les réponses, consultez les réponses d’action personnalisée. Les actions personnalisées sans persistance du lac de données constituent la solution idéale lorsque les données ne sont utiles qu’à l’intérieur du parcours et que le système externe est accessible via un point d’entrée de l’API. Pour une comparaison de toutes les options d’accès aux données, consultez Choisir votre stratégie d’accès aux données .
Les API REST utilisant POST ou GET et renvoyant du JSON sont prises en charge. Les modes d’authentification par clé API, de base et personnalisée sont pris en charge.
Prenons l’exemple d’un service API météorologique que je souhaite utiliser pour personnaliser les comportements de mon parcours en fonction des données météorologiques en temps réel.
Voici deux exemples d’appel API :
- https://api.adobeweather.org/weather?city=London,uk&appid=1234
- https://api.adobeweather.org/weather?lat=35&lon=139&appid=1234
L’appel est composé d’une URL principale (https://api.adobeweather.org/weather), de deux jeux de paramètres (« city » pour la ville et « lat/long » pour la latitude et la longitude) et la clé API (appid).
cacheDuration de Journey Optimizer, en particulier en cas de lourdes charges de travail, afin d’éviter les décalages d’expiration et les erreurs 401.Création et configuration d’une source de données externe create-ext-data-sources
Les principales étapes de création et de configuration d’une source de données externe sont les suivantes :
-
Dans la liste des sources de données, cliquez sur Créer une source de données pour créer une source de données externe.
Le volet de configuration de la source de données s’ouvre alors dans la partie droite de l’écran.
-
Saisissez un nom pour votre source de données.
Seuls les caractères alphanumériques et les traits de soulignement sont autorisés. La longueur maximale est de 30 caractères.
-
Ajoutez une description à votre source de données. Cette étape est facultative.
-
Ajoutez l’URL du service externe. Dans notre exemple : https://api.adobeweather.org/weather.
note caution CAUTION Nous vous recommandons vivement d'utiliser le protocole HTTPS pour des raisons de sécurité. Notez également que l’utilisation d’adresses Adobe qui ne sont pas publiquement disponibles et d’adresses IP n’est pas autorisée. 
-
Configurez l’authentification en fonction de la configuration du service externe : Aucune authentification, Simple, Personnalisée ou Clé API.
Pour le mode d’authentification simple, vous devez renseigner un nom d’utilisateur ou d’utilisatrice et un mot de passe.
note NOTE -
Lorsque l’appel d’authentification est effectué, la chaîne
<username>:<password>, codée en base64, est ajoutée dans l’en-tête Authentification. -
Adobe Journey Optimizer chiffre automatiquement les secrets définis dans les actions personnalisées. Les clés de chiffrement de chaque organisation sont gérées en toute sécurité dans un coffre dédié lié à leur organisation. Lorsque les informations d’identification s’affichent dans l’interface, elles sont masquées par défaut afin d’éviter toute exposition accidentelle.
Pour plus d’informations sur le mode d’authentification personnalisée, consultez cette la section Mode d’authentification personnalisée. Dans notre exemple, nous choisissons le mode d’authentification par clé API, comme présenté ci-dessous :
-
Type : « clé API »
-
Nom : « appid » (il s’agit du nom du paramètre de la clé API)
-
Valeur : « 1234 » (valeur de la clé API)
-
Emplacement : « Paramètre de requête » (la clé API se trouve dans l’URL).
-
-
Ajoutez un nouveau groupe de champs pour chaque jeu de paramètres API en cliquant sur Ajouter un nouveau groupe de champs. Seuls les caractères alphanumériques et les traits de soulignement sont autorisés dans le nom du groupe de champs. La longueur maximale est de 30 caractères. Dans notre exemple, nous devons créer deux groupes de champs, un pour chaque jeu de paramètres (city et long/lat).
Pour le jeu de paramètres « long/lat », nous créons un groupe de champs avec les informations suivantes :
- Utilisé dans : affiche le nombre de parcours qui utilisent un groupe de champs. Vous pouvez cliquer sur l’icône Afficher les parcours pour afficher la liste des parcours utilisant ce groupe de champs.
- Méthode : sélectionnez la méthode POST ou GET. Dans notre cas, nous sélectionnons la méthode GET.
- Valeurs dynamiques : saisissez les différents paramètres séparés par une virgule, « long,lat » dans notre exemple. Les valeurs des paramètres dépendant du contexte d’exécution, elles seront définies dans les parcours. En savoir plus sur les expressions
- Payload de réponse : cliquez dans le champ Payload et collez un exemple du payload renvoyé par l’appel. Dans notre exemple, nous avons utilisé un payload trouvé sur un site web d’API météorologique. Vérifiez que les types de champ sont corrects. À chaque appel de l’API, le système récupère tous les champs contenus dans l’exemple de payload. Notez que vous pouvez cliquer sur Coller un nouveau payload si vous souhaitez modifier le payload actuellement transmis.
- Payload envoyé : ce champ n’apparaît pas dans notre exemple. Il n’est disponible que si vous sélectionnez la méthode POST. Collez le payload qui sera envoyé au système tiers.
Dans le cas d’une méthode GET nécessitant un ou plusieurs paramètres, vous saisissez le ou les paramètres dans le champ Valeurs dynamiques et ils sont automatiquement ajoutés à la fin de l’appel. Dans le cas d’un appel POST, vous devez procéder comme suit :
- répertorier les paramètres à transmettre au moment de l’appel dans le champ Valeurs dynamiques (« identifiant » dans l’exemple ci-dessous) ;
- spécifier les paramètres avec la même syntaxe dans le corps de la payload envoyée. Pour ce faire, vous devez ajouter : « param » : « nom de votre paramètre » (« identifiant » dans l’exemple ci-dessous). Suivez la syntaxe ci-dessous :
{"id":{"param":"identifier"}}
Une fois vos modifications enregistrées, la source de données est configurée et prête à être utilisée dans vos parcours, par exemple dans vos conditions ou pour personnaliser un e-mail. Si la température est supérieure à 30 °C, vous pouvez choisir d’envoyer une communication spécifique.
Mode d’authentification personnalisé custom-authentication-mode
Ce mode d’authentification personnalisée est utilisé pour une authentification complexe. Il est fréquemment utilisé pour appeler les protocoles d’encapsulage d’API, comme OAuth2, afin de récupérer un jeton d’accès à injecter dans la requête HTTP réelle pour l’action.
Lorsque vous configurez l’authentification personnalisée, utilisez le bouton Cliquer pour vérifier l’authentification pour contrôler si la payload d’authentification personnalisée est correctement configurée.
Si le test est réussi, le bouton devient vert.
Avec ce mode d’authentification, l’exécution de l’action est un processus en deux étapes :
- Appelez le point d’entrée pour générer le jeton d’accès.
- Appelez l’API REST en injectant correctement le jeton d’accès.
Définition du point d’entrée à appeler pour générer le jeton d’accès custom-authentication-endpoint
-
endpoint: URL à utiliser pour générer le point d’entrée -
Méthode de la requête HTTP sur le point d’entrée (
GETouPOST) -
headers: paires clé-valeur à injecter en tant qu’en-têtes dans cet appel, si nécessaire -
body: décrit le corps de l’appel si la méthode est POST. Nous prenons en charge une structure de corps limitée, définie dans bodyParams (paires clé-valeur). bodyType décrit le format et le codage du corps dans l’appel :form: signifie que le type de contenu sera application/x-www-form-urlencoded (jeu de caractères UTF-8) et que les paires clé/valeur seront sérialisées comme suit : key1=value1&key2=value2&…json: signifie que le type de contenu sera application/json (jeu de caractères UTF-8) et que les paires clé-valeur seront sérialisées sous la forme d’un objet json, tel quel : { “key1”: “value1”, “key2”: “value2”, …}
Définition de la méthode d’injection du jeton d’accès dans la requête HTTP de l’action custom-authentication-access-token
-
authorizationType : définit la manière dont le jeton d’accès généré doit être injecté dans l’appel HTTP pour l’action. Les valeurs possibles sont les suivantes :
bearer: indique que le jeton d’accès doit être injecté dans l’en-tête Authorization, par exemple Authorization: Bearer <jeton d’accès>header: indique que le jeton d’accès doit être injecté en tant qu’en-tête, le nom de l’en-tête étant défini par la propriététokenTarget. Par exemple, sitokenTargetestmyHeader, le jeton d’accès est injecté sous la forme d’un en-tête : myHeader: <jeton d’accès>queryParam: indique que le jeton d’accès doit être injecté en tant que queryParam, le nom du paramètre de requête défini par la propriété tokenTarget. Par exemple, si tokenTarget est myQueryParam, l’URL de l’appel d’action est : <url>?myQueryParam=<jeton d’accès>
-
tokenInResponse : indique comment extraire le jeton d’accès de l’appel d’authentification. Cette propriété peut être l’un des éléments suivants :
response: indique que la réponse HTTP est le jeton d’accès.- Sélecteur dans un fichier json (en supposant que la réponse soit un fichier json, nous ne prenons pas en charge d’autres formats, tels que XML). Le format de ce sélecteur est json://<chemin d’accès à la propriété du jeton d’accès>. Par exemple, si la réponse de l’appel est : { "access token": “theToken”, “timestamp”: 12323445656 }, tokenInResponse sera : json: //access_token_.
Le format de cette authentification est le suivant :
{
"type": "customAuthorization",
"endpoint": "<URL of the authentication endpoint>",
"method": "<HTTP method to call the authentication endpoint, in 'GET' or 'POST'>",
(optional) "headers": {
"<header name>": "<header value>",
...
},
(optional, mandatory if method is 'POST') "body": {
"bodyType": "<'form'or 'json'>,
"bodyParams": {
"param1": value1,
...
}
},
"tokenInResponse": "<'response' or json selector in format 'json://<field path to access token>'",
"cacheDuration": {
(optional, mutually exclusive with 'duration') "expiryInResponse": "<json selector in format 'json://<field path to expiry>'",
(optional, mutually exclusive with 'expiryInResponse') "duration": <integer value>,
"timeUnit": "<unit in 'milliseconds', 'seconds', 'minutes', 'hours', 'days', 'months', 'years'>"
},
"authorizationType": "<value in 'bearer', 'header' or 'queryParam'>",
(optional, mandatory if authorizationType is 'header' or 'queryParam') "tokenTarget": "<name of the header or queryParam if the authorizationType is 'header' or 'queryParam'>",
}
Vous pouvez modifier la durée de mise en cache du jeton pour une source de données d’authentification personnalisée. Vous trouverez ci-dessous un exemple de payload d’authentification personnalisé. La durée de mise en cache est définie dans le paramètre cacheDuration. Il spécifie la durée de conservation du jeton généré dans le cache. L’unité peut être les millisecondes, les secondes, les minutes, les heures, les jours, les mois ou les années.
Voici un exemple pour le type d’authentification bearer :
{
"type": "customAuthorization",
"endpoint": "https://<your_auth_endpoint>/epsilon/oauth2/access_token",
"method": "POST",
"headers": {
"Authorization": "Basic EncodeBase64(<epsilon Client Id>:<epsilon Client Secret>)"
},
"body": {
"bodyType": "form",
"bodyParams": {
"scope": "cn mail givenname uid employeeNumber",
"grant_type": "password",
"username": "<epsilon User Name>",
"password": "<epsilon User Password>"
}
},
"tokenInResponse": "json://access_token",
"cacheDuration": {
"duration": 5,
"timeUnit": "minutes"
},
},
-
Le jeton d’authentification est mis en cache par parcours : si deux parcours utilisent la même action personnalisée, chaque parcours dispose de son propre jeton mis en cache. Ce jeton n’est pas partagé entre ces parcours.
-
La durée de mise en cache permet d’éviter un trop grand nombre d’appels aux points d’entrée d’authentification. La durée de conservation du jeton d’authentification est mise en cache dans les services, il n’y a aucune persistance. Si un service est redémarré, il commence par un cache propre. Par défaut, la durée de mise en cache est de 1 heure. Dans la payload d’authentification personnalisée, elle peut être adaptée en spécifiant une autre durée de rétention.
Authentification personnalisée basée sur un certificat certificate-credential
Pour les API d’entreprise qui appliquent la vérification d’identité avec certificat, telles que l’identifiant Microsoft Entra, vous pouvez configurer une authentification personnalisée avec certificat en ajoutant "subType": "certificateCredential" à votre payload d’autorisation personnalisée. Par défaut, Journey Optimizer utilise un certificat géré Adobe pour signer une assertion client JWT avec RS256 et l’échanger contre un jeton d’accès. Aucun secret client n’est requis pour cette option de RS256 par défaut. La même payload prend également en charge la signature HMAC avec votre secret client OAuth au lieu d’un certificat Adobe.
Cette option ajoute deux champs obligatoires au schéma de customAuthorization standard : subType et aud. Tous les autres champs (endpoint, method, paramètres de corps, tokenInResponse) restent inchangés. En l’absence de subType, le comportement est identique à celui de l’authentification personnalisée standard. Les configurations existantes ne sont pas affectées.
subType: à définir sur"certificateCredential"pour activer l’authentification par certificat.aud: valeur d’audience incluse dans l’assertion cliente JWT. Pour Microsoft Entra ID, il s’agit de la même que l’URLendpoint, mais elle doit toujours être explicitement définie.alg(facultatif) : algorithme de signature JWT. Les valeurs prises en charge sontRS256(par défaut),HS256,HS384etHS512. Lorsquealgest absent ou défini surRS256, le flux RSA existant s’exécute sans modification. Toute autre valeur, y compris les minuscules, est rejetée lorsque l’authentification est testée ou exécutée. Configurez ce champ dans la payload d’autorisation personnalisée ; il n’existe pas de contrôle d’interface utilisateur distinct pour l’algorithme de signature.
Les champs client_assertion et client_assertion_type ne sont jamais créés par l’utilisateur ou l’utilisatrice. Ils sont automatiquement injectés par la plateforme au moment de l’exécution, immédiatement avant l’appel du point d’entrée du jeton.
Fonctionnement de RS256’authentification certificate-credential-how-it-works
L’authentification personnalisée basée sur des certificats implémente les informations d’identification clientes OAuth 2.0 avec une assertion cliente JWT, comme défini dans RFC 7523, la même norme prise en charge par Microsoft Entra ID et Okta. Au lieu d’un secret client, Journey Optimizer prouve son identité à l’aide d’un JWT signé avec une clé privée gérée Adobe. Votre fournisseur d’identité vérifie la signature à l’aide du certificat public Adobe, que vous enregistrez une fois dans votre fournisseur d’identité.
L’échange de jetons suit les étapes suivantes :
- Journey Optimizer crée une assertion cliente JWT signée avec une clé privée Adobe.
- L’assertion est envoyée à votre point d’entrée de jeton avec vos
client_id,grant_typeetscope. - Votre fournisseur d’identité vérifie la signature JWT par rapport au certificat public enregistré Adobe.
- Votre fournisseur d’identité renvoie un jeton d’accès du porteur.
- Journey Optimizer utilise ce jeton pour appeler votre point d’entrée d’action personnalisé.
Détails du certificat Adobe certificate-credential-details
Pour l’option de RS256 par défaut, Adobe gère le certificat et sa clé privée associée. Le tableau suivant résume ses propriétés clés. Ces exigences de certificat ne s’appliquent pas à la signature HMAC.
expiryDate et reconfigurer votre fournisseur d’identité avant la révocation de l’ancien certificat.Adobe renouvelle automatiquement le certificat 60 jours avant son expiration. Le certificat précédent reste valide jusqu’à 30 jours avant l’expiration. Les clients ne sont actuellement pas avertis. Consultez le mécanisme de sécurisation Certificat (RS256 uniquement) ci-dessous pour savoir comment surveiller la rotation par programmation.
Gardez à l’esprit les mécanismes de sécurisation suivants lors de la configuration de l’authentification personnalisée par certificat :
- URL du point d’entrée du jeton : doit être HTTPS. Évitez les URL contenant des
?. Cela indique que le point d’entrée d’autorisation a été collé à la place du point d’entrée de jeton. method: doit êtrePOST. Les points d’entrée de jeton OAuth acceptent uniquement les requêtes POST.client_id: ne doit pas être vide et ne doit pas contenir d’espaces de début ou de fin. Une valeur vide génère un jeton JWT d’aspect valide que le fournisseur d’identité rejettera avec une erreur opaque.scope: exprimé sous la forme d’une chaîne unique séparée par des espaces dansbodyParams. Maximum 1 000 caractères au total.- Certificat (RS256 uniquement) : Adobe gère le certificat et la clé privée ; vous ne téléchargez ni ne saisissez de certificat. Avant d’utiliser l’action personnalisée dans un parcours dynamique avec RS256, vous devez enregistrer le certificat feuille d’Adobe dans votre fournisseur d’identité. Pour le récupérer, appelez l’API de certificat public mTLS et recherchez l’entrée où
certCommonNameestajo-journeys.aep-mtls.adobe.com. Enregistrez la valeurpublicCertificatede cette entrée, et non les certificats d’autorité de certification intermédiaire ou racine. Comme les clientes et clients ne sont actuellement pas avertis du renouvellement du certificat, vous devez appeler régulièrement l’API de certificat public mTLS pour vérifier laexpiryDateet mettre à jour le certificat enregistré dans votre fournisseur d’identité avant que l’ancien certificat ne soit révoqué 30 jours avant son expiration. La signature HMAC ne nécessite pas l’enregistrement d’un certificat Adobe.
Vous n’êtes pas l’auteur de l’assertion du client JWT, Journey Optimizer la génère et la signe pour vous. La structure attendue est fournie ici afin que votre équipe de fournisseurs d’identité puisse valider les revendications.
L’en-tête et la payload suivants s’appliquent à l’option de RS256 par défaut. Pour connaître les différences HMAC, voir Assertions du client JWT signées HMAC.
En-tête :
{
"alg": "RS256",
"x5t": "<base64url SHA-1 thumbprint of Adobe's leaf certificate>"
}
Payload :
{
"iss": "<client_id>",
"sub": "<client_id>",
"aud": ["<aud value>"],
"iat": "<current unix timestamp>",
"exp": "<iat + 600 seconds>",
"jti": "<unique UUID per request>"
}
Prenez note des points suivants :
- Par RS256, la
expestiat+ 600 secondes (10 minutes), conformément aux exigences d’Okta et d’Entra ID. Pour HMAC,expest deiat+ 300 secondes (5 minutes). - Chaque assertion utilise un
jtiunique, ce qui la protège contre les attaques par rejeu. client_assertionetclient_assertion_typesont injectés automatiquement par la plateforme et ne sont jamais créés.
Voici un exemple pour le type d’authentification des informations d’identification du certificat, pour Microsoft Entra ID :
{
"type": "customAuthorization",
"subType": "certificateCredential",
"aud": "https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token",
"authorizationType": "Bearer",
"endpoint": "https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token",
"method": "POST",
"body": {
"bodyType": "form",
"bodyParams": {
"client_id": "<your-client-id>",
"grant_type": "client_credentials",
"scope": "https://api.example.com/.default"
}
},
"tokenInResponse": "json://access_token"
}
Voici un exemple pour le même type d’authentification d’informations d’identification de certificat, pour Okta :
{
"type": "customAuthorization",
"subType": "certificateCredential",
"authorizationType": "bearer",
"endpoint": "https://<your-okta-domain>/oauth2/v1/token",
"aud": "https://<your-okta-domain>/oauth2/v1/token",
"method": "POST",
"body": {
"bodyType": "form",
"bodyParams": {
"client_id": "<your-okta-app-client-id>",
"grant_type": "client_credentials",
"scope": "<your-api-scope>"
}
},
"tokenInResponse": "json://access_token"
}
Voici un exemple pour le type d’authentification de l’en-tête :
{
"type": "customAuthorization",
"endpoint": "https://myapidomain.com/v2/user/login",
"method": "POST",
"headers": {
"x-retailer": "any value"
},
"body": {
"bodyType": "form",
"bodyParams": {
"secret": "any value",
"username": "any value"
}
},
"tokenInResponse": "json://token",
"cacheDuration": {
"expiryInResponse": "json://expiryDuration",
"timeUnit": "minutes"
},
"authorizationType": "header",
"tokenTarget": "x-auth-token"
}
Voici un exemple de réponse de l’appel API de connexion :
{
"token": "xDIUssuYE9beucIE_TFOmpdheTqwzzISNKeysjeODSHUibdzN87S",
"expiryDuration" : 5
}
bodyParams) sont pris en charge.Assertions client JWT signées HMAC hmac-credential
Pour utiliser la signature HMAC, définissez alg sur HS256, HS384 ou HS512 dans la payload d’autorisation personnalisée. Journey Optimizer utilise votre client_secret OAuth comme clé de signature. Votre fournisseur d’identité doit accepter les client_secret_jwt avec le même secret et le même algorithme. Aucun enregistrement de certificat Adobe n’est requis.
HMAC nécessite les mêmes champs que RS256 : "subType": "certificateCredential", un aud explicite, "method": "POST", "bodyType": "form" et client_id dans body.bodyParams. Ajoutez en outre des client_secret à body.bodyParams. Les longueurs secrètes minimales sont mesurées en octets UTF-8, et non en caractères :
client_secretJourney Optimizer n’envoie pas de client_secret au point d’entrée du jeton. Il envoie les autres bodyParams créées et ajoute automatiquement les client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer et les client_assertion.
Le jeton JWT HMAC utilise typ: JWT et le alg sélectionné, sans x5t, et exp est iat + 300 secondes, contre 600 secondes pour RS256.
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains how to create and configure external data sources that connect to third-party REST APIs, including the supported authentication modes, field group setup, custom authentication payloads, and certificate-based custom authentication.
Intents:
- Create and configure an external data source that connects to a third-party REST API
- Choose an authentication mode among No authentication, Basic, Custom, and API key
- Define field groups per API parameter set with Method, Dynamic Values, and payload fields
- Configure custom authentication for protocols such as OAuth2 and check it with the Click to check the authentication button
- Configure JWT client assertion authentication using default RS256 certificate signing or optional HMAC signing
- Set the token cache duration to limit calls to the authentication endpoint
Glossary:
- External data source: A connection to a third-party system that you create; you can create as many as you need (product-specific)
- Field group: A set of fields configured per API parameter set, with Method, Dynamic Values, Response Payload, and (for POST) Sent Payload (product-specific)
- Custom authentication mode: An authentication mode for complex protocols such as OAuth2, where the action execution is a two-step process that first generates an access token and then injects it in the HTTP request (product-specific)
- cacheDuration: The parameter that specifies the retention duration of the generated token in the cache (product-specific)
- Certificate-based custom authentication: A custom authentication subtype (
subType: certificateCredential) where Journey Optimizer signs a JWT client assertion and exchanges it for an access token; the default RS256 option uses Adobe’s managed certificate and requires no client secret (product-specific) - HMAC-signed JWT client assertion: An assertion signed using the OAuth
client_secretas the signing key, selected through the optionalalgfield, without Adobe certificate registration (product-specific)
Guardrails:
- Use custom actions instead of data sources for external data source use cases now that responses are supported (recommended). Custom Actions without Data Lake persistence are the right choice when the data is only useful inside the journey and the external system is accessible via an API endpoint.
- REST APIs using POST or GET and returning JSON are supported; API Key, basic, and custom authentication modes are supported.
- The use of Adobe addresses that are not publicly available and the use of IP addresses is not allowed; HTTPS is strongly recommended for security reasons.
- Data source name: only alphanumeric characters and underscores are allowed, maximum length 30 characters (hard limit).
- Field group name: only alphanumeric characters and underscores are allowed, maximum length 30 characters (hard limit).
- The Sent Payload field is only available if you select the POST method.
- The default cache duration is 1 hour (default) and can be adapted in the custom authentication payload; at least a one-minute buffer between the external API’s token expiration period and the
cacheDurationsetting is recommended, especially under heavy workloads, to avoid expiration mismatches and 401 errors. - The authentication token is cached per journey and is not shared between journeys; there is no persistence, so a service restart starts with a clean cache.
- Encode64 is the only function available in the authentication payload.
- For certificate-based custom authentication,
subTypeandaudare mandatory; the token endpoint URL must be HTTPS,methodmust bePOST,client_idmust not be blank and must have no leading or trailing whitespace. - For certificate-based custom authentication,
scopeis a single space-separated string inbodyParams, maximum 1000 characters total (hard limit). - For RS256 only, you never upload or enter a certificate; before using the custom action in a live journey you must register Adobe’s leaf certificate (not the intermediate or root CA) in your Identity Provider.
- The Adobe certificate applies to the default RS256 (RSA) option; Adobe rotates it 60 days before expiry (certificate lifetime 13 months) and the previous certificate remains valid until 30 days before expiry; customers are not currently notified, so periodically call the mTLS Public Certificate API to check the
expiryDate. - The optional
algfield acceptsRS256(default),HS256,HS384, andHS512. Omittingalgor setting it toRS256preserves the existing RSA flow; any other value, including lowercase, is rejected when the authentication is tested or executed. - HMAC-signed JWT authentication is available in Limited Availability.
- HMAC signing requires
client_idandclient_secretinbody.bodyParams,subType: certificateCredential, explicitaud,method: POST, andbodyType: form. Minimum secret lengths in UTF-8 bytes are 32 for HS256, 48 for HS384, and 64 for HS512. The identity provider client must acceptclient_secret_jwtwith the same secret and algorithm. - For HMAC, Journey Optimizer does not send
client_secretin the token request; it sends the other authoredbodyParamsplusclient_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerandclient_assertion. - The HMAC JWT header includes
typand the selectedalg, with nox5t;expisiat+ 300 seconds. RS256 usesiat+ 600 seconds. - When configuring custom authentication for a custom action, nested JSON objects (for example, sub-objects within
bodyParams) are supported.
Terminology:
- Canonical name: external data source - variants: external data sources
- Do not confuse: Dynamic Values (parameters defined in journeys and passed at call time) ≠ Response Payload (example payload returned by the call) ≠ Sent Payload (payload sent to the third-party system, POST only)
- Do not confuse: “RS256” (default JWT signing with Adobe’s managed certificate) and “HS256”, “HS384”, or “HS512” (HMAC JWT signing with the OAuth client secret)
FAQ:
- Q: What kinds of APIs are supported for external data sources? — REST APIs using POST or GET and returning JSON, with API Key, basic, or custom authentication modes.
- Q: What is the maximum length of a data source or field group name? — 30 characters, using only alphanumeric characters and underscores.
- Q: How do I verify that my custom authentication payload is configured correctly? — Use the Click to check the authentication button; when the test is successful, the button turns green.
- Q: What is the default token cache duration and can I change it? — The default cache duration is 1 hour, and you can adapt it by specifying another retention duration in the
cacheDurationparameter of the custom authentication payload. - Q: Do I need to upload a certificate for certificate-based custom authentication? - For the default RS256 option, Adobe manages the certificate and private key; you register Adobe’s leaf certificate in your Identity Provider, retrieved from the mTLS Public Certificate API. HMAC signing requires no Adobe certificate registration.
- Q: Are nested JSON objects allowed when configuring custom authentication for a custom action? — Yes, nested JSON objects such as sub-objects within
bodyParamsare supported.
Personas:
- developer: Can configure field groups with Method, Dynamic Values, Response Payload, and Sent Payload fields for each API parameter set. Can pass parameters in a GET call through Dynamic Values, or match them in a POST call body using the param syntax. The page states that the Sent Payload field is only available when you select the POST method. Where: “Create and configure an external data source”.
- admin: Can create an external data source with a name limited to alphanumeric characters and underscores, maximum 30 characters. Can select No authentication, Basic, Custom, or API key authentication modes, and set the cache duration for custom authentication tokens. The page states that Adobe addresses that are not publicly available and IP addresses are not allowed, and HTTPS is strongly recommended. Where: “Guardrails”.
Onboarding:
- Level: Intermediate, Experienced
- First minimal step: From the list of data sources, select Create Data Source to create a new external data source.
- Success check: Once your changes are saved, the data source is configured and ready to be used in your journeys.
- Previous: Comparing all data access options before choosing an external data source: Get started with data sources (datasource/about-data-sources.md); Checking guardrails for external systems before configuring a connection: Integrate Journey Optimizer with external systems (configuration/external-systems.md)
- Next: Using custom actions instead of data sources now that responses are supported: Custom action enhancements (action/action-response.md); Learning more about expressions for Dynamic Values parameters defined in journeys: Work with the advanced expression editor (building-journeys/expression/expressionadvanced.md)