Visão geral da API de administração do Target

Este artigo fornece uma visão geral das informações de referência necessárias para entender e usar o Adobe Target Admin APIs com êxito. O conteúdo a seguir pressupõe que você entende como configurar a autenticação para Adobe Target Admin APIs.

Antes de começar

Em todos os exemplos de código fornecidos para as APIs de administrador, substitua {tenant} pelo seu valor de locatário, your-bearer-token pelo token de acesso gerado com seu JWT e your-api-key pela sua chave de API da Adobe Developer Console. Para obter mais informações sobre locatários e JWTs, consulte o artigo sobre como configurar a autenticação para APIs de administrador do Adobe Target.

Controle de versão

Todas as APIs têm uma versão associada. É importante fornecer a versão correta da API que você deseja usar.

Se a solicitação tiver uma carga (POST ou PUT), o cabeçalho Content-Type da solicitação será usado para especificar a versão.

Se a solicitação não contiver uma carga (GET, DELETE ou OPTIONS), o cabeçalho Accept será usado para especificar a versão.

Se uma versão não for fornecida, a chamada assumirá V1 como padrão (application/vnd.adobe.target.v1+json).

Mensagem de erro para recursos sem suporte

{
    "httpStatus": 406,
    "requestId": "8752b736-cf71-4d81-86c3-94be2b5ae648",
    "requestTime": "2018-02-02T21:39:06.405Z",
    "errors": [
        {
            "errorCode": "Unsupported.Feature",
            "message": "Unsupported features detected"
        }
    ]
}

Admin Postman Collection

O Postman é um aplicativo que facilita o acionamento de chamadas de API. Esta Coleção do Postman da API de administração do Target contém todas as chamadas da API de administração do Target que exigem autenticação usando Atividades, Públicos, Ofertas, Relatórios, Mboxes e Ambientes

Códigos de resposta

Estes são os códigos de resposta comuns para as APIs de administrador do Target.

Atividades

Uma atividade permite testar ou personalizar o conteúdo para seus usuários. As atividades podem ser de um dos seguintes tipos:

Atualizações em lote

Várias APIs de administrador podem ser executadas como uma única solicitação em lote.

Executar chamadas em lote

POST /{tenant}/target/batch

Empilhe várias chamadas de API e execute-as em um único lote.

O agrupamento em lotes permite passar instruções para várias operações em uma única solicitação HTTP. Você também pode especificar dependências entre operações relacionadas (descritas em uma seção abaixo). O TNT processará cada uma de suas operações independentes (possivelmente em paralelo) e processará suas operações dependentes sequencialmente. Depois que todas as operações forem concluídas, uma resposta consolidada será enviada de volta e a conexão HTTP será fechada.

A API de lote recebe uma matriz de solicitações HTTP lógicas representadas como matrizes JSON - cada solicitação tem um método (correspondente ao método HTTP GET/PUT/POST/DELETE etc.), um relativeUrl (a parte do URL após admin/rest/), matriz de cabeçalhos opcionais (correspondente a cabeçalhos HTTP) e um corpo opcional (para solicitações POST e PUT). A API de lote retorna uma matriz de respostas HTTP lógicas representadas como matrizes JSON - cada resposta tem um código de status, uma matriz de cabeçalhos opcionais e um corpo opcional (que é uma cadeia de caracteres codificada em JSON). Para fazer solicitações em lote, crie um objeto JSON que descreve cada operação individual a ser executada. O número máximo de operações permitidas é de 256 (de 0 a 255).

Especificando dependências entre operações na solicitação Por padrão, as operações especificadas na solicitação da API em lote são independentes - elas podem ser executadas em ordem arbitrária no servidor e um erro em uma operação não afeta a execução de outras operações.

Geralmente, as operações na solicitação são dependentes - por exemplo, a saída de uma operação pode ser usada na entrada da próxima operação. Por exemplo, a oferta criada em operationId=0 precisa ser usada na criação da campanha operationId=1.

Para vincular duas operações em lote, especifique na operação dependente a ID da operação necessária, por exemplo: "dependsOnOperationId" : 5. Além disso, as IDs de recursos criados por meio de solicitações POST de operações em lote podem ser usadas em operações dependentes, em "relativeUrl" e "body".

Permissões e limitação

Para executar ações de API em lote, o usuário subjacente deve ter pelo menos direitos de "editor" (para cada operação individual, caso sejam necessários direitos adicionais, em vez de o usuário ter, a operação individual falhará). As estratégias de limitação comuns são aplicadas em ações de API em lote como se cada operação tivesse sido executada individualmente.

O processamento em lote é concluído quando todas as operações são concluídas. Uma operação pode ser bem-sucedida (2xx statusCode), com falha (4xx, 5xx status code) ou ignorada porque uma operação de dependência falhou ou foi ignorada.

Parâmetros do objeto de solicitação

Exemplo de objeto de solicitação

{
  "operations": [
    {
      "operationId": 1,
      "dependsOnOperationIds~": [0],
      "method": "POST",
      "relativeUrl": "/v1/offers",
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "body~": {
        "key": "value"
      }
    }
  ]
}

Parâmetros do Objeto de Resposta

Exemplo de objeto de resposta

{
  "results": [
    {
      "operationId": 1,
      "skipped~": false,
      "statusCode~": 200,
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json; charset=UTF-8"
        }
      ],
      "body~": {
        "id": 5
      }
    }
  ]
}