ACDA (App Content Delivery API)

Última atualização: 22 de junho de 2026

A ACDA (App Content Delivery API) é uma API somente leitura que entrega o Content e a Media publicados aos membros inscritos no produto, ou seja, aos ServiceUser. Quando quem opera a Space publica o conteúdo, os membros o leem por meio da ACDA. Pense nela como a versão para ServiceUser que desempenha, com a identidade de membro, o mesmo papel que a CDA cumpre ao entregar conteúdo publicado a visitantes públicos. A ACDA possui apenas endpoints de consulta (GET); criar, atualizar e excluir são responsabilidade da ACMA.

As chamadas à ACDA usam o token Bearer emitido pelo ServiceLogin. Esse token é válido somente na ACMA e na ACDA, e não pode ser usado na CMA nem na CDA (para o fluxo de emissão do token, consulte a Auth API).

Diferenças em relação à CDA

O formato de resposta da ACDA é igual ao da CDA. Ela entrega apenas o snapshot do material publicado (em sys não inclui version, status nem publish, apenas revision, a versão do momento da publicação) e define o idioma a receber com locale na consulta. As diferenças em relação à CDA são o escopo de leitura e a identidade.

  • Escopo de leitura por membro: na CDA, qualquer pessoa que faça a chamada com um único DeliveryAccessToken vê o mesmo conjunto publicado. A ACDA retorna apenas o que é permitido ao ServiceUser que fez a chamada, e o que é permitido depende do ServiceUserRole e das atribuições desse membro. A identidade também é diferente. A CDA é chamada com o DeliveryAccessToken; a ACDA, com o token de membro emitido pelo ServiceLogin.

A forma de definir em qual idioma receber por meio do parâmetro de consulta locale também é igual à da CDA. Ao informar um código, como locale=ko-KR, os fields retornam com um único valor desse locale (se não houver e o Fallback não alcançar, vem vazio ou null); ao omitir, retornam do mesmo modo com o Locale padrão da Space; e ao informar locale=*, retorna tal como está o mapa com os valores de todos os locales. Nos dois primeiros casos, em que se recebe um único idioma, vem o cabeçalho x-weegloo-locale, que informa o locale efetivamente usado (quando locale=*, ele não é incluído).

Estrutura do recurso

A seguir está o formato em que a ACDA entrega um Content "produto" da Space de demonstração. É o resultado de uma consulta com locale=ko-KR, e cada valor de fields está presente como um único valor de ko-KR.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "revision": 3
  },
  "fields": {
    "productName": "스테인리스 텀블러 500ml",
    "price": 18000,
    "description": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량."
  }
}

Chaves principais:

  • sys.id: identificador único do Content. Entra em {contentId} no caminho da consulta individual.
  • sys.type: tipo do recurso; para Content é sempre "Content".
  • sys.space: referência que aponta para a Space à qual este Content pertence.
  • sys.contentType: referência que aponta para o Content Type que este Content segue.
  • sys.revision: versão do momento em que foi publicado. A cada publicação, a versão daquele momento é registrada aqui. Como a ACDA não inclui os campos administrativos version, status e publish, o único valor que aponta para a versão publicada é revision.
  • sys.createdBy e sys.updatedBy: incluídos apenas quando o publishWithAuthor do Content Type está ativado, apontando para o autor e quem alterou. No exemplo acima essa opção está desativada, por isso as duas chaves foram omitidas.
  • fields: contém o valor de cada campo no formato { apiName: value }. Ao contrário do mapa de locales da CMA e da ACMA ({ apiName: { locale: value } }), a ACDA contém apenas o único valor do locale consultado. No exemplo acima, a foto principal photo foi omitida por não ter valor nesse locale.

A Media também retorna no mesmo formato de entrega de publicação, contendo apenas revision em sys e não incluindo version, status nem publish. A Media sempre omite as informações de autoria (createdBy e updatedBy). O fields.file da Media também retorna como um único objeto do locale consultado.

API

Os três endpoints são consultas (GET) e definem o idioma a receber por meio do parâmetro de consulta locale (se for um código, esse locale; se omitido, o Locale padrão; se *, o mapa completo, veja acima).

  • ACMA: API de gerenciamento com que o membro cria e altera o próprio conteúdo.
  • Auth API: emissão do token de chamada à ACDA.
  • Login de ServiceUser (conceito): configuração de ServiceLogin, ServiceUserRole e atribuições.