Información general de API de administración de Target
- Temas:
- APIs/SDKs
Creado para:
- Desarrollador
Este artículo proporciona información general sobre la información básica necesaria para comprender y usar Adobe Target Admin API correctamente. El siguiente contenido supone que usted comprende cómo configurar la autenticación para Adobe Target Admin APIs.
NOTEAntes de empezar
En todos los ejemplos de código proporcionados para las API de administrador, reemplace {tenant} por su valor de inquilino, your-bearer-token por el token de acceso que genere con su JWT y your-api-key por su clave de API de Adobe Developer Console. Para obtener más información sobre inquilinos y JWT, consulte el artículo sobre cómo configurar la autenticación para las API de administración de Adobe Target.
Versiones
Todas las API tienen una versión asociada. Es importante proporcionar la versión correcta de la API que desee utilizar.
Si la solicitud contiene una carga útil (POST o PUT), se utiliza el encabezado Content-Type de la solicitud para especificar la versión.
Si la solicitud no contiene una carga útil (GET, DELETE o OPTIONS), se utiliza el encabezado Accept para especificar la versión.
Si no se proporciona una versión, la llamada predeterminada será V1 (application/vnd.adobe.target.v1+json).
NOTEMensaje de error para funciones no admitidas
{
"httpStatus": 406,
"requestId": "8752b736-cf71-4d81-86c3-94be2b5ae648",
"requestTime": "2018-02-02T21:39:06.405Z",
"errors": [
{
"errorCode": "Unsupported.Feature",
"message": "Unsupported features detected"
}
]
}
Colección de Admin Postman
Postman es una aplicación que facilita la activación de llamadas de API. Esta recopilación de Postman de la API de administración de Target contiene todas las llamadas a la API de administración de Target que requieren autenticación mediante actividades, audiencias, ofertas, informes, mboxes y entornos
Códigos de respuesta
Estos son los códigos de respuesta comunes para las API de administrador de Target.
Actividades
Una actividad de le permite probar o personalizar el contenido para los usuarios. Las actividades pueden ser de uno de los siguientes tipos:
Actualizaciones por lotes
Se pueden ejecutar varias API de administrador como una sola solicitud por lotes.
Ejecutar llamadas en lote
POST /{tenant}/target/batch
Apilar varias llamadas de API y ejecutarlas en un solo lote.
El agrupamiento permite pasar instrucciones para varias operaciones en una única solicitud HTTP. También puede especificar dependencias entre operaciones relacionadas (descritas en una sección a continuación). TNT procesará cada una de sus operaciones independientes (posiblemente en paralelo) y procesará sus operaciones dependientes secuencialmente. Una vez completadas todas las operaciones, se devolverá una respuesta consolidada y se cerrará la conexión HTTP.
La API por lotes admite una matriz de solicitudes HTTP lógicas representadas como matrices JSON: cada solicitud tiene un método (correspondiente al método HTTP GET/PUT/POST/DELETE, etc.), relativeUrl (la parte de la URL después de admin/rest/), una matriz de encabezados opcional (correspondiente a los encabezados HTTP) y un cuerpo opcional (para las solicitudes de POST y PUT). La API por lotes devuelve una matriz de respuestas HTTP lógicas representadas como matrices JSON . Cada respuesta tiene un código de estado, una matriz de encabezados opcional y un cuerpo opcional (que es una cadena codificada en JSON). Para realizar solicitudes por lotes, cree un objeto JSON que describa cada operación individual que se va a realizar. El número máximo de operaciones permitidas es de 256 (de 0 a 255).
Especificación de dependencias entre operaciones en la solicitud De forma predeterminada, las operaciones especificadas en la solicitud de API por lotes son independientes: se pueden ejecutar en orden arbitrario en el servidor y un error en una operación no afecta a la ejecución de otras operaciones.
A menudo, las operaciones de la solicitud dependen, por ejemplo, la salida de una operación se puede utilizar en la entrada de la siguiente operación. Por ejemplo, la oferta creada en operationId=0 debe utilizarse en la creación de campañas operationId=1.
Para vincular dos operaciones por lotes, especifique en la operación dependiente el ID de la operación requerida, por ejemplo: "dependsOnOperationId" : 5. Además, los ID de los recursos creados mediante solicitudes de POST de operaciones por lotes se pueden utilizar en operaciones dependientes tanto en "relativeUrl" como en "body".
Permisos y limitación
Para ejecutar acciones de API por lotes, el usuario subyacente debe tener al menos derechos de "editor" (para cada operación individual en caso de que se requieran derechos adicionales que el usuario, la operación individual fallará). Las estrategias de regulación habituales se aplican en acciones de API por lotes como si cada operación se hubiera realizado individualmente.
El procesamiento por lotes finaliza cuando se han completado todas las operaciones, una operación podría ser correcta (código de estado 2xx), fallida (código de estado 4xx, 5xx) o se omitirá porque una operación de dependencia ha fallado o se ha omitido.
Parámetros de objeto de solicitud
Objeto de solicitud de ejemplo
{
"operations": [
{
"operationId": 1,
"dependsOnOperationIds~": [0],
"method": "POST",
"relativeUrl": "/v1/offers",
"headers~": [
{
"name": "Content-Type",
"value": "application/json"
}
],
"body~": {
"key": "value"
}
}
]
}
Parámetros de objeto de respuesta
Objeto de respuesta de ejemplo
{
"results": [
{
"operationId": 1,
"skipped~": false,
"statusCode~": 200,
"headers~": [
{
"name": "Content-Type",
"value": "application/json; charset=UTF-8"
}
],
"body~": {
"id": 5
}
}
]
}