ACMA (App Content Management API)

A ACMA (App Content Management API) é a API com a qual os membros inscritos no produto, ou seja, os ServiceUser, manipulam diretamente Content e Media. Pode pensar nela como a execução, sob a identidade do membro, das mesmas tarefas que um Weegloo User realiza ao manipular conteúdo pela CMA. O membro cria (Create), lê (Read), altera (Update) e exclui (Delete) Content e Media pela ACMA. O âmbito permitido de cada operação é definido pelo ServiceUserRole.

As chamadas à ACMA usam o token Bearer emitido pelo ServiceLogin. Esse token só é válido na ACMA e na ACDA, e não pode ser usado na CMA ou na CDA (para o fluxo de emissão do token, consulte a Auth API). O Content Type, que é o molde seguido pelo membro, não é criado nem alterado na ACMA. O Content Type é gerido pelo Weegloo User na CMA, e a ACMA não possui endpoints de criação ou edição de Content Type.

Diferenças em relação à CMA

A ACMA corresponde à CMA, mas difere na identidade, no âmbito de propriedade e no comportamento de publicação.

Um membro cujo ServiceUser.isAdmin seja true pode, adicionalmente, apenas excluir os dados de outros membros. Trata-se de uma permissão acrescentada por cima das operações que o papel permite, e não significa que aumentem as permissões de edição ou de leitura sobre os dados de outros membros. E mesmo isso só é possível dentro do âmbito de operações que o ServiceUserRole desse membro permitir.

Para uma explicação detalhada dos comportamentos acima (âmbito de propriedade, publicação automática na criação, anulação automática de publicação na exclusão, âmbito do isAdmin), consulte Login do ServiceUser (conceito).

Minhas informações (Me)

GET /me devolve as informações do próprio ServiceUser do token atual. Diferentemente da CMA, chama-se /me diretamente, sem passar pelo caminho do Space.

A seguir está a estrutura da resposta de um ServiceUser. O sys contém a identidade e as informações de inscrição, e o corpo contém atributos de exibição como nickname e avatarUrl.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ",
    "type": "ServiceUser",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "provider": "google",
    "email": "minji.kim@example.com",
    "createdAt": "2026-06-17T09:12:03.114Z",
    "updatedAt": "2026-06-17T09:12:03.114Z"
  },
  "nickname": "Minji",
  "avatarUrl": "https://lh3.googleusercontent.com/a/example-avatar",
  "enableLogin": true,
  "isAdmin": false
}

Chaves principais:

• sys.id: identificador único do ServiceUser. O createdBy do Content e do Media criados pelo membro aponta para este valor.
• sys.type: tipo de recurso; para ServiceUser é sempre "ServiceUser".
• sys.space: referência que aponta para o Space ao qual este membro pertence.
• sys.provider: provedor usado no login (ex.: google).
• sys.email: endereço de e-mail fornecido pelo provedor de login.
• nickname: nome de exibição do membro (obrigatório).
• avatarUrl: endereço da imagem de perfil (opcional).
• roleOverride: referência que aponta para outro ServiceUserRole quando se quer aplicar um papel diferente apenas a este membro (opcional). Se não for definido, segue o papel padrão do ServiceLogin.
• enableLogin: indica se o login é permitido.
• isAdmin: se true, pode excluir os dados de outros membros (consulte Diferenças em relação à CMA acima).

Apenas nickname e avatarUrl podem ser editados. Valores como provider, email e isAdmin não são alterados diretamente pelo membro.

Content

Content é um dado individual que segue um molde chamado Content Type. No caso de uma loja de roupas online, cada produto que segue o Content Type "Produto" é um Content. Na ACMA, o membro manipula o seu Content pelo caminho vinculado ao Space e ao Content Type (/spaces/{spaceId}/content-types/{contentTypeId}/contents).

A seguir está um Content "Produto" do Space de demonstração.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 3,
      "at": "2026-06-16T14:35:11.210Z",
      "firstAt": "2026-06-15T15:16:20.180Z",
      "counter": 3,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 4,
    "status": "Published"
  },
  "fields": {
    "price": { "ko-KR": 18000 },
    "description": { "ko-KR": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량." },
    "photo": {},
    "productName": { "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

Chaves principais:

• sys.id: identificador único do Content. Entra no {contentId} dos caminhos de consulta individual, edição e exclusão.
• sys.contentType: referência que aponta para o Content Type que este Content segue.
• sys.status: estado de publicação. O Content criado na ACMA é publicado de imediato e retorna como Published.
• sys.version: versão do recurso; aumenta em 1 a cada alteração.
• sys.publish: histórico de publicação (version, at, firstAt, counter, by).
• fields: contém o valor de cada campo no formato { apiName: { locale: value } }. O exemplo acima contém price, description, photo e productName no locale ko-KR. Um campo sem valor (photo) é um objeto vazio.
• metadata.tags: lista de Tag anexadas a este Content.

A consulta de lista recebe os parâmetros de query padrão (limit, skip, next, prev, order, select, include), e a resposta devolve em conjunto o array items e os links (cursores de página).

Media

Media é um arquivo enviado como ativo (imagem, vídeo, documento etc.). Para o membro criar um Media, primeiro envia o arquivo pela Upload API e recebe um Upload, depois inclui o sys.id desse Upload na requisição de criação do Media. O Media também é publicado automaticamente junto com a criação na ACMA.

A seguir está um Media de foto de uma garrafa térmica enviada ao Space de demonstração.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGjUMsPV3uU",
    "type": "Media",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-15T15:17:30.825Z",
      "firstAt": "2026-06-15T15:17:30.825Z",
      "counter": 1,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:17:30.589Z",
    "updatedAt": "2026-06-15T15:17:30.825Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "title": { "ko-KR": "스테인리스 텀블러 500ml 정면 컷" },
    "description": { "ko-KR": "흰 배경에서 찍은 텀블러 정면 제품 사진입니다." },
    "file": {
      "ko-KR": {
        "fileName": "tumbler.png",
        "contentType": "image/png",
        "mimeGroups": ["Image"],
        "url": "https://weegloo-media.com/medias/HnQ32YiH/3uU/3trmXRM3RqbgSnifyg7OGjUMsPV3uU/ko-KR/1/tumbler.png",
        "detail": { "size": 50847, "image": { "width": 900, "height": 900 } }
      }
    }
  },
  "metadata": { "tags": [] }
}

Chaves principais:

• sys.id: identificador único do Media. Entra no {mediaId} dos caminhos de consulta individual e exclusão, e é o valor para o qual o Content aponta quando referencia a foto.
• sys.status: estado de publicação. O Media criado na ACMA é publicado de imediato e retorna como Published.
• fields.title e fields.description: contêm o título e a descrição do ativo como um mapa por locale (opcional).
• fields.file: informação do arquivo por locale (obrigatório). Quando o processamento termina, são preenchidos url (endereço de entrega), mimeGroups e detail (tamanho, resolução da imagem etc.).

No fields.file da requisição de criação de Media coloca-se a referência do Upload em estado anterior ao processamento. Cada item de arquivo inclui fileName, contentType, mimeGroups, state e upload, sendo state sempre "PENDING" e upload contendo o sys.id do Upload recebido pela Upload API. Logo após a criação, a plataforma processa o arquivo e, ao terminar o processamento, url e detail são preenchidos como na resposta acima.

Documentos relacionados

• Auth API: o fluxo OAuth para obter o token usado nas chamadas à ACMA.
• ACDA: a API de leitura que entrega conteúdo publicado aos membros.
• Login do ServiceUser (conceito): configuração de ServiceLogin e ServiceUserRole.
• Upload API: envio do arquivo antes de criar o Media.