Información general de API de administración de Target
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.
NOTAAntes 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).
NOTAMensaje 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.
| Estado | Significado | Descripción |
|---|---|---|
| 200 | ACEPTAR | Aceptar |
| 400 | Solicitud incorrecta | Solicitud incorrecta. Lo más probable es que los datos proporcionados en la solicitud no sean válidos. |
| 401 | No autorizado | El usuario no tiene permiso para realizar esta operación. |
| 403 | Prohibido | El acceso a este recurso está prohibido. |
| 404 | No encontrado | No se ha encontrado el recurso al que se hace referencia. |
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
| Atributo | Descripción | Límites | Valor predeterminado |
|---|---|---|---|
| cuerpo | cuerpo para la operación por lotes HTTP. se ignorarán para todas las acciones excepto POST y PUT. Puede hacer referencia a los ID de acciones por lotes anteriores, por ejemplo: "offerId": "{operationIdResponse:0}", "segmentId": "{operationIdResponse:1}" | debe ser un JSON válido; en caso de hacer referencia a un operationIdResponse, la respuesta de operationId debe ser un ID válido y el método de esa acción debe ser un POST | objeto vacío {} |
| dependsOnOperationIds | Lista de ID de restricción que garantiza que la operación actual se ejecutará sólo si las operaciones especificadas se han completado correctamente. Se puede utilizar para lograr encadenar operaciones. | se permiten un máximo de 255 operaciones; solo se permiten valores únicos; debe señalar a un operationId válido en la matriz; no se permiten dependencias cíclicas | |
| encabezados | matriz de encabezados clave-valor que se enviarán con una operación determinada. Si la autenticación para la API por lotes se ha realizado mediante el encabezado Autorización, también se copiará para operaciones individuales. | el número máximo de encabezados permitidos en la matriz es 50 | Content-Type: application/json |
| headers->name | nombre del encabezado | debe ser único entre otros nombres de encabezado. rfc no distingue entre mayúsculas y minúsculas en los encabezados; de lo contrario, los valores se anularán entre sí. | |
| headers->value | valor de encabezado | N/A | cadena vacía |
| method | Método HTTP para utilizar. Opciones disponibles: GET, POST, PUT, PATCH DELETE | solo se permiten los métodos GET, POST, PUT, PATCH y DELETE | |
| operationId | ID de operación utilizado para identificar una operación, entre otras operaciones, para obtener respuestas y resultados de referencia. | único entre otras operaciones; valores entre 0 y 255 | |
| operaciones | lista de operaciones para realizar en un lote. El orden no es relevante. | se permiten un máximo de 256 operaciones | |
| relativeUrl | URL relativa para la API de rest de administrador, la parte después de "/admin/rest/". Puede contener parámetros de cadena de consulta como: "/v2/campaigns?limit=10&offset=10". Puede hacer referencia a direcciones URL con ID de contenedores de acciones por lotes anteriores, por ejemplo: "/v1/offers/{operationIdResponse:0}". En caso de que se envíen parámetros de consulta, deben codificarse con la dirección URL. | debe comenzar por / (ser relativo); solo se admiten nuevas API de JSON válidas; en caso de una URL relativa no válida, se devolverá una respuesta 404 para una operación en particular; en caso de hacer referencia a un operationIdResponse, la respuesta de operationId referida debe ser un ID válido y el método en esa acción debe ser POST |
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
| Parámetro | Descripción |
|---|---|
| operationId | ID de operación utilizado para identificar una operación, entre otras operaciones, el mismo ID con el que se envió en la solicitud del POST. |
| omitido | indicador booleano para marcar si la operación se ha ejecutado o omitido. Será verdadero en caso de que la operación actual dependa de una operación que ha fallado (devuelto un valor statusCode diferente a 2xx). |
| statusCode | Si se devuelven, todas las operaciones dependientes se omitirán (no se ejecutarán). |
| encabezados | matriz de encabezados clave-valor que se enviarán como respuesta a una operación concreta. |
| headers->name | nombre del encabezado |
| headers->value | valor de encabezado |
| cuerpo | cuerpo de la operación de respuesta por lotes HTTP |
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
}
}
]
}
