Documentación Journey Optimizer Guía de Journey Optimizer

Fuentes de datos externas external-data-sources

Última actualización: 16 de octubre de 2026

Creado para:

Intermedio
Experimentado
Administrador
Desarrollador

En esta página: Conéctese a las API de REST de terceros y configure la autenticación para poder extraer datos externos en sus recorridos para condiciones y personalización.

style

shade-box

Trabajo con fuentes de datos externas gs-ext-data-sources

Las fuentes de datos externas le permiten definir una conexión a sistemas de terceros, por ejemplo, si utiliza un sistema de reserva de hoteles para comprobar si la persona ha reservado una habitación. A diferencia de la fuente de datos integrada Adobe Experience Platform, puede crear tantas fuentes de datos externas como necesite.

NOTE

Las protecciones al trabajar con sistemas externos se enumeran en esta página.
Como las respuestas ahora son compatibles, debe utilizar acciones personalizadas en lugar de fuentes de datos para casos de uso de fuentes de datos externas. Para obtener más información sobre las respuestas, consulte respuestas de acciones personalizadas. Las acciones personalizadas sin persistencia de lago de datos son la opción correcta cuando los datos solo son útiles dentro del recorrido y el sistema externo es accesible a través de un punto final de API. Para ver una comparación de todas las opciones de acceso a datos, consulte Elegir una estrategia de acceso a datos.

Las API de REST que utilizan POST o GET y arrojan JSON son compatibles. Se admiten los modos de autenticación básica y personalizada de la clave de API.

Veamos el ejemplo de un servicio de API meteorológica que quiero usar para personalizar el comportamiento de mi recorrido según los datos del tiempo real.

Estos son dos ejemplos de llamada API:

https://api.adobeweather.org/weather?city=London,uk&appid=1234
https://api.adobeweather.org/weather?lat=35&lon=139&appid=1234

La llamada se compone de una dirección URL principal (https://api.adobeweather.org/weather), dos conjuntos de parámetros (“ciudad” para la ciudad y “lat/long” para la latitud y longitud) y la clave de API (appid).

TIP

Se recomienda dejar al menos un minuto de búfer entre el período de caducidad del token de la API externa y la configuración de Journey Optimizer cacheDuration , especialmente en cargas de trabajo pesadas, para evitar discrepancias de caducidad y errores 401.

Creación y configuración de una fuente de datos externa create-ext-data-sources

A continuación se muestran los pasos principales para crear y configurar una nueva fuente de datos externa:

En la lista de orígenes de datos, haga clic en Crear Source de datos para crear un nuevo origen de datos externo.

Se abre el panel de configuración de la fuente de datos en el lado derecho de la pantalla.
Escriba un nombre para la fuente de datos.

Solo se permiten caracteres alfanuméricos y guiones bajos. La longitud máxima es de 30 caracteres.

Añada una descripción a la fuente de datos. Este paso es opcional.

Añada la dirección URL del servicio externo. En nuestro ejemplo: https://api.adobeweather.org/weather.

note caution
CAUTION
Recomendamos encarecidamente utilizar HTTPS por motivos de seguridad. Tenga en cuenta también que no permitimos el uso de direcciones de Adobe que no están disponibles para el público ni de direcciones IP.

Campo de dirección URL de origen de datos externo con ejemplo de extremo de API meteorológica ingresado

Configure la autenticación según la configuración del servicio externo: Sin autenticación, Básico, Personalizado o Clave de API.

Para el modo de autenticación básico, debe introducir un nombre de usuario y una contraseña.

note

NOTE

Cuando se realiza la llamada de autenticación, se agrega la cadena <username>:<password>, codificada en base64, en el encabezado Autenticación.
Adobe Journey Optimizer cifra automáticamente los secretos definidos en las acciones personalizadas. Las claves de cifrado de cada organización se administran de forma segura en un almacén dedicado vinculado a su organización. Cuando las credenciales se muestran en la interfaz de, se enmascaran de forma predeterminada para evitar una exposición accidental.

Para obtener más información acerca del modo de autenticación personalizado, vea la sección sobre el modo de autenticación personalizado. En nuestro ejemplo, elegimos el modo de autenticación de clave de API, como se muestra a continuación:

Tipo: “clave de API”
Nombre: “appid” (el nombre del parámetro de clave de API)
Valor: “1234” (el valor de nuestra clave de API)
Ubicación: “Parámetro de consulta” (la clave de API se encuentra en la dirección URL)

Agregue un nuevo grupo de campos para cada conjunto de parámetros de API haciendo clic en Agregar nuevo grupo de campos. El nombre del grupo de campos solo puede contener caracteres alfanuméricos y guiones bajos. La longitud máxima es de 30 caracteres. En nuestro ejemplo, necesitamos crear dos grupos de campos, uno para cada conjunto de parámetros (city y long/lat).

Para el conjunto de parámetros “long/lat”, creamos un grupo de campos con la siguiente información:

Utilizado en: muestra el número de recorridos que utilizan un grupo de campos. Puede hacer clic en el icono Ver recorridos para mostrar la lista de recorridos usando este grupo de campos.
Método: seleccione el método POST o GET. En nuestro caso, seleccionamos el método GET.
Valores dinámicos: escriba los diferentes parámetros separados por una coma, “long,lat” en nuestro ejemplo. Dado que los valores de parámetro dependen del contexto de ejecución, se definirán en los recorridos. Más información sobre las expresiones
Carga de respuesta: haga clic dentro del campo Carga útil y pegue un ejemplo de la carga útil devuelta por la llamada. Para nuestro ejemplo, hemos utilizado una carga útil encontrada en un sitio web de la API meteorológica. Compruebe que los tipos de campo son correctos. Cada vez que se llama a la API, el sistema recupera todos los campos incluidos en el ejemplo de carga útil. Tenga en cuenta que puede hacer clic en Pegar una nueva carga útil si desea cambiar la carga útil que se pasa actualmente.
Carga útil enviada: este campo no aparece en nuestro ejemplo. Solo está disponible si selecciona el método POST. Pegue la carga útil que se enviará al sistema de terceros.

En el caso de una llamada GET que requiera parámetros, ingrese los parámetros en el campo Valores dinámicos y se agregarán automáticamente al final de la llamada. En caso de una llamada POST, debe hacer esto:

enumera los parámetros que se pasarán en el momento de la llamada en el campo Valores dinámicos (en el ejemplo siguiente: “identificador”).
Especificarlos también con la misma sintaxis en el cuerpo de la carga útil enviada. Para ello, debe agregar: “param”: “nombre del parámetro” (en el ejemplo siguiente: “identificador”). Siga esta sintaxis:

{"id":{"param":"identifier"}}

Panel de configuración de grupo de campos con valores dinámicos y campos de carga de respuesta

Una vez guardados los cambios, la fuente de datos está configurada y lista para utilizarse en los recorridos, por ejemplo en las condiciones o para personalizar un correo electrónico. Si la temperatura es superior a 30 °C, puede decidir enviar una comunicación específica.

Modo de autenticación personalizado custom-authentication-mode

El modo de autenticación personalizado se utiliza para la autenticación compleja, utilizada frecuentemente para llamar a protocolos de ajuste de API como OAuth2, para recuperar un token de acceso que se va a insertar en la petición HTTP real de la acción.

Cuando configure la autenticación personalizada, use Haga clic para comprobar el botón de autenticación y controlar si la carga de autenticación personalizada está configurada correctamente.

Botón de prueba de autenticación personalizada en la configuración de la fuente de datos

Cuando la prueba se realiza correctamente, el botón se vuelve verde.

El botón de prueba de autenticación se volvió verde indicando una validación correcta

Con este modo de autenticación, la ejecución de la acción es un proceso de dos pasos:

Llame al extremo para generar el token de acceso.
Llame a la API de REST mediante la inyección adecuada del token de acceso.

NOTE

Esta autenticación consta de dos partes.

Definición del extremo al que se va a llamar para generar el token de acceso custom-authentication-endpoint

endpoint: dirección URL que se utilizará para generar el extremo
método de la petición HTTP en el extremo (GET o POST)
headers: pares clave-valor que se insertarán como encabezados en esta llamada si es necesario
body: describe el cuerpo de la llamada si el método es POST. Apoyamos una estructura de cuerpo limitada, definida en bodyParams (pares clave-valor). bodyType describe el formato y la codificación del cuerpo en la llamada:
- form: lo que significa que el tipo de contenido será application/x-www-form-urlencoded (charset UTF-8) y que los pares clave-valor se serializarán tal cual: key1=value1&key2=value2&…
- json: lo que significa que el tipo de contenido será application/json (charset UTF-8) y que los pares clave-valor se serializarán como un objeto json tal cual: { “key1”: “value1”, “key2”: “value2”, …}

Definición de la forma en que se debe insertar el token de acceso en la petición HTTP de la acción custom-authentication-access-token

authorizationType: define cómo se debe insertar el token de acceso generado en la llamada HTTP para la acción. Los valores posibles son:
- bearer: indica que el token de acceso debe inyectarse en el encabezado Autorización, como: Autorización: Portador <token de acceso>
- header: indica que el token de acceso debe insertarse como encabezado, el nombre del encabezado definido por la propiedad tokenTarget. Por ejemplo, si tokenTarget es myHeader, el token de acceso se insertará como un encabezado como: myHeader: <token de acceso>
- queryParam: indica que el token de acceso debe insertarse como queryParam, el nombre del parámetro de consulta definido por la propiedad tokenTarget. Por ejemplo, si tokenTarget es myQueryParam, la dirección URL de la llamada de acción será: <url>?myQueryParam=<token de acceso>
tokenInResponse: indica cómo extraer el token de acceso de la llamada de autenticación. Esta propiedad puede ser:
- response: indica que la respuesta HTTP es el token de acceso
- un selector en un json (suponiendo que la respuesta es un json, no se admiten otros formatos como XML). El formato de este selector es json://<ruta a la propiedad token de acceso>. Por ejemplo, si la respuesta de la llamada es: { "access token": “theToken”, “timestamp”: 12323445656 }, tokenInResponse será: json: //access_token_

El formato de esta autenticación es:

{
    "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'>",
}

NOTE

Encode64 es la única función disponible en la carga útil de autenticación.

Puede cambiar la duración de caché del token para una fuente de datos de autenticación personalizada. A continuación se muestra un ejemplo de una carga útil de autenticación personalizada. La duración de la caché se define en el parámetro cacheDuration. Especifica la duración de retención del token generado en la caché. La unidad puede ser milisegundos, segundos, minutos, horas, días, meses, años.

Este es un ejemplo del tipo de autenticación del portador:

{
    "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"
    },
  },

NOTE

El token de autenticación se almacena en caché por recorrido: si dos recorridos utilizan la misma acción personalizada, cada recorrido tiene su propio token en caché. Ese token no se comparte entre esos recorridos.
La duración de la caché ayuda a evitar demasiadas llamadas a los extremos de autenticación. La retención del token de autenticación se almacena en caché en los servicios, no hay persistencia. Si se reinicia un servicio, se inicia con una caché limpia. La duración de la caché de forma predeterminada es de 1 hora. En la carga útil de autenticación personalizada, se puede adaptar especificando otra duración de retención.

Autenticación personalizada basada en certificados certificate-credential

En el caso de las API empresariales que aplican la verificación de identidad basada en certificados, como Microsoft Entra ID, puede configurar la autenticación personalizada basada en certificados agregando "subType": "certificateCredential" a la carga útil de autorización personalizada. De manera predeterminada, Journey Optimizer utiliza el certificado administrado de Adobe para firmar una aserción de cliente JWT con RS256 e intercambiarla por un token de acceso. No se requiere secreto de cliente para esta opción predeterminada RS256. La misma carga útil también admite firma HMAC con el secreto de cliente de OAuth en lugar de un certificado de Adobe.

Esta opción agrega dos campos obligatorios al esquema estándar customAuthorization: subType y aud. Todos los demás campos (endpoint, method, parámetros de cuerpo, tokenInResponse) permanecen sin cambios. Cuando subType está ausente, el comportamiento es idéntico al de la autenticación personalizada estándar: las configuraciones existentes no se ven afectadas.

subType: se establece en "certificateCredential" para activar la autenticación basada en certificados.
aud: el valor de audiencia incluido en la afirmación del cliente JWT. Para el Microsoft Entra ID, es igual que la URL endpoint, pero siempre se debe establecer explícitamente.
alg (opcional): algoritmo de firma JWT. Los valores admitidos son RS256 (predeterminado), HS256, HS384 y HS512. Cuando alg está ausente o establecido en RS256, el flujo RSA existente se ejecuta sin cambios. Cualquier otro valor, incluidas las minúsculas, se rechaza cuando se prueba o ejecuta la autenticación. Configure este campo en la carga útil de autorización personalizada; no hay ningún control de IU independiente para el algoritmo de firma.

El usuario nunca crea los campos client_assertion y client_assertion_type. La plataforma los inserta automáticamente durante la ejecución, inmediatamente antes de la llamada del extremo del token.

Cómo funciona la autenticación RS256 certificate-credential-how-it-works

La autenticación personalizada basada en certificados implementa las credenciales del cliente OAuth 2.0 con una aserción de cliente JWT, tal como se define en RFC 7523, el mismo estándar admitido por Microsoft Entra ID y Okta. En lugar de un secreto de cliente, Journey Optimizer prueba su identidad mediante un JWT firmado con la clave privada administrada de Adobe. Su proveedor de identidad verifica la firma utilizando el certificado público de Adobe, que usted registra una vez en su proveedor de identidad.

El intercambio de tokens sigue estos pasos:

Journey Optimizer crea una afirmación de cliente JWT firmada con la clave privada de Adobe.
La afirmación se envía al extremo de token junto con sus client_id, grant_type y scope.
Su proveedor de identidad verifica la firma JWT con el certificado público registrado de Adobe.
El proveedor de identidad devuelve un token de acceso al portador.
Journey Optimizer utiliza ese token para llamar al extremo de la acción personalizada.

Detalles del certificado de Adobe certificate-credential-details

Para la opción predeterminada RS256, Adobe administra el certificado y su clave privada asociada. La siguiente tabla resume sus propiedades clave. Estos requisitos de certificado no se aplican a la firma HMAC.

Propiedad

Valor

Emitido por

DigiCert (CA pública)

Administrado por

Adobe

Algoritmo

RS256 (RSA), la opción de firma JWT predeterminada

Qué debe registrarse en su proveedor de identidad

Solo certificado hoja de Adobe, no la CA intermedia o raíz

Cómo obtener

Recuperarlo de la API de certificado público mTLS (consulte la protección de Certificado a continuación)

Rotación

Adobe gira automáticamente el certificado 60 días antes de la caducidad (duración del certificado: 13 meses). El certificado anterior sigue siendo válido hasta 30 días antes de su expiración. Actualmente no se notifica a los clientes sobre la rotación: llame periódicamente a la API de certificados públicos de mTLS para comprobar expiryDate y volver a configurar el IDP antes de que se revoque el certificado antiguo.

Adobe gira automáticamente el certificado 60 días antes de la caducidad. El certificado anterior sigue siendo válido hasta 30 días antes de su expiración. Actualmente no se notifica a los clientes. Consulte la protección Certificado (solo RS256) más abajo para ver cómo supervisar la rotación mediante programación.

Estructura de afirmación de JWT certificate-credential-jwt

Tenga en cuenta las siguientes protecciones al configurar la autenticación personalizada basada en certificados:

URL de extremo de token: debe ser HTTPS. Evite las direcciones URL que contengan ?; se trata de un signo de que el extremo de autorización se pegó en lugar del extremo de token.
method: debe ser POST. Los extremos de token de OAuth solo aceptan solicitudes POST.
client_id: no debe estar en blanco y no debe tener espacios iniciales o finales. Un valor en blanco produce un JWT de aspecto válido que el proveedor de identidad rechazará con un error opaco.
scope: expresado como una sola cadena separada por espacios en bodyParams. Máximo 1000 caracteres en total.
Certificado (solo RS256): Adobe administra el certificado y la clave privada; nunca carga ni introduce un certificado. Antes de usar la acción personalizada en un recorrido activo con RS256, debe registrar el certificado hoja de Adobe en su proveedor de identidad. Para recuperarlo, llame a la API de certificado público mTLS y busque la entrada donde certCommonName es ajo-journeys.aep-mtls.adobe.com. Registre el valor publicCertificate de esa entrada, no los certificados de CA intermedia o raíz. Dado que actualmente no se notifica a los clientes de la rotación de certificados, debe llamar periódicamente a la API de certificados públicos de mTLS para comprobar expiryDate y actualizar el certificado registrado en el IDP antes de que el certificado antiguo se revoque 30 días antes de la caducidad. La firma de HMAC no requiere el registro de certificados de Adobe.

style

shade-box

No es el autor de la afirmación del cliente JWT, Journey Optimizer la genera y la firma. La estructura esperada se proporciona aquí para que el equipo del proveedor de identidad pueda validar las notificaciones.

El encabezado y la carga útil siguientes se aplican a la opción predeterminada RS256. Para ver las diferencias entre HMAC, consulte Afirmaciones de cliente JWT firmadas por HMAC.

Encabezado:

{
  "alg": "RS256",
  "x5t": "<base64url SHA-1 thumbprint of Adobe's leaf certificate>"
}

Carga útil:

{
  "iss": "<client_id>",
  "sub": "<client_id>",
  "aud": ["<aud value>"],
  "iat": "<current unix timestamp>",
  "exp": "<iat + 600 seconds>",
  "jti": "<unique UUID per request>"
}

Tenga en cuenta lo siguiente:

Para RS256, exp es iat + 600 segundos (10 minutos), coherente con los requisitos de ID de Okta y Entra. Para HMAC, exp es iat + 300 segundos (5 minutos).
Cada aserción utiliza un único jti, lo que hace que sea seguro volver a reproducir el ataque.
La plataforma inserta automáticamente client_assertion y client_assertion_type, y nunca los crea.

Este es un ejemplo del tipo de autenticación de credencial de certificado, para 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"
}

Este es un ejemplo para el mismo tipo de autenticación de credencial de certificado, para 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"
}

Este es un ejemplo del tipo de autenticación de encabezado:

{
  "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"
}

A continuación, se muestra un ejemplo de la respuesta de la llamada de API de inicio de sesión:

{
  "token": "xDIUssuYE9beucIE_TFOmpdheTqwzzISNKeysjeODSHUibdzN87S",
  "expiryDuration" : 5
}

CAUTION

Al configurar la autenticación personalizada para una acción personalizada, tenga en cuenta que se admiten objetos JSON anidados (por ejemplo, subobjetos dentro de bodyParams).

Afirmaciones de cliente JWT firmadas por HMAC hmac-credential

AVAILABILITY

La autenticación JWT firmada por HMAC está disponible en disponibilidad limitada.

Para usar la firma HMAC, establezca alg en HS256, HS384 o HS512 en la carga útil de autorización personalizada. Journey Optimizer usa su OAuth client_secret como clave de firma. Su proveedor de identidad debe aceptar client_secret_jwt con el mismo secreto y algoritmo. No se requiere ningún registro de certificado de Adobe.

HMAC requiere los mismos campos que RS256: "subType": "certificateCredential", un aud, "method": "POST", "bodyType": "form" y client_id explícito en body.bodyParams. Además, agregue client_secret a body.bodyParams. Las longitudes secretas mínimas se miden en bytes UTF-8, no en caracteres:

Algoritmo

Longitud mínima de client_secret

HS256

32 bytes

HS384

48 bytes

HS512

64 bytes

Journey Optimizer no envía client_secret al extremo del token. Envía el otro bodyParams creado y agrega automáticamente client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer y client_assertion.

El JWT de HMAC utiliza typ: JWT y el alg seleccionado, sin x5t, y exp es iat + 300 segundos, en comparación con los 600 segundos de RS256.

AI Knowledge Reference

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_secret as the signing key, selected through the optional alg field, 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 cacheDuration setting 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, subType and aud are mandatory; the token endpoint URL must be HTTPS, method must be POST, client_id must not be blank and must have no leading or trailing whitespace.
For certificate-based custom authentication, scope is a single space-separated string in bodyParams, 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 alg field accepts RS256 (default), HS256, HS384, and HS512. Omitting alg or setting it to RS256 preserves 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_id and client_secret in body.bodyParams, subType: certificateCredential, explicit aud, method: POST, and bodyType: form. Minimum secret lengths in UTF-8 bytes are 32 for HS256, 48 for HS384, and 64 for HS512. The identity provider client must accept client_secret_jwt with the same secret and algorithm.
For HMAC, Journey Optimizer does not send client_secret in the token request; it sends the other authored bodyParams plus client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer and client_assertion.
The HMAC JWT header includes typ and the selected alg, with no x5t; exp is iat + 300 seconds. RS256 uses iat + 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 cacheDuration parameter 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 bodyParams are supported.

recommendation-more-help

journey-optimizer-help