Content

Content é um registro de dados real moldado a partir de um Content Type (o gabarito). Tomando uma loja de roupas como exemplo, o Content Type "Produto" define a composição de itens como nome do produto, preço e descrição detalhada, e um "Stainless Tumbler 500ml" é um Content que segue esse gabarito.

Content é composto por duas partes. fields contém os valores reais de cada campo, e sys contém estados como publicação, versão e arquivamento. Na CMA, Content é um recurso filho de Space, e os caminhos de consulta e exclusão têm como base /spaces/{spaceId}/contents, enquanto os caminhos de criação e modificação têm como base /spaces/{spaceId}/content-types/{contentTypeId}/contents, sob o Content Type. As operações de gestão são realizadas na CMA, e o snapshot publicado é entregue pela CDA.

Estrutura do recurso

A seguir está a resposta de uma consulta individual do Content publicado "Stainless Tumbler 500ml". Junto com sys (propriedades de sistema), ele possui fields (valores dos campos) e metadata (informações adicionais como tags).

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 1,
      "at": "2026-06-18T09:51:44.128Z",
      "firstAt": "2026-06-18T09:51:44.128Z",
      "counter": 1,
      "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
    },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:51:14.597Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:51:44.128Z",
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "price": { "en-US": 18000 },
    "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

Chaves principais:

• sys.id: identificador único do Content. Entra no {contentId} dos caminhos de consulta individual, modificação, exclusão e publicação.
• sys.contentType: o Refer que aponta para o Content Type que este Content segue.
• fields: os valores de cada campo. A chave é o apiName do campo, e o valor é um mapa por Locale. Explicado abaixo em A chave de fields é o apiName.
• metadata.tags: a lista de Tag aplicadas a este Content. Cada item tem o formato Refer<Tag>, e quando não há tags é um array vazio [].

A chave de fields é o apiName

A chave do objeto fields é o apiName de cada campo. Não é o id interno do Content Type nem o nome do campo exibido no estúdio de conteúdo (por exemplo, Nome do produto). Por isso, ao criar ou ler um Content, você deve usar como chave o apiName definido no Content Type.

O mapeamento entre os campos do Content Type "Produto" de demonstração e seu apiName é o seguinte.

O valor de cada campo é um mapa por Locale. O formato do valor depende de localized.

• Um campo localized: true pode ter valores em vários Locale, no formato { "<locale>": valor }. Por exemplo: "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }.
• Um campo localized: false (campo não dependente) recebe um valor apenas sob a chave do Locale padrão do Space. Nenhuma outra chave de Locale é permitida. Como o Locale padrão do Space de demonstração é en-US, o preço tem apenas a chave en-US, como em "price": { "en-US": 18000 }.

Qual é o Locale padrão, até qual Locale um campo required deve ser preenchido e a regra de fallback quando não há valor são tratados em Multilíngue (conceito).

Formato do valor por tipo

O formato do valor que entra dentro da chave de Locale segue o type do campo. A maioria dos tipos recebe diretamente o valor daquele tipo (os tipos de texto recebem uma string, Number e Long recebem um número, Boolean recebe true/false). Os tipos cujo formato é um objeto ou array e por isso geram mais confusão são os seguintes.

• Location: é um objeto { "latitude": <número>, "longitude": <número> }. O latitude fica entre -90 e 90, o longitude fica entre -180 e 180, e as duas chaves são obrigatórias. Como não aceita nenhuma chave além das definidas, usar chaves abreviadas como lat, lng ou lon resulta em rejeição.
• Refer: o valor é um objeto Refer que aponta para o alvo; em vez de colocar apenas a string do id, coloca-se diretamente o objeto sys. Quando aponta para outro Content, o targetType é Content; quando aponta para um Media, é Media. O formato do próprio Refer é definido em Formato do Refer nas propriedades de sistema (sys).
• Array: é um array JSON que contém os valores do tipo de elemento. Se o elemento for texto, é um array de strings; se o elemento for Refer (Content ou Media), é um array de objetos Refer. Não é um array de strings de id.

A seguir está um exemplo dos valores que entram dentro de fields (quando o Locale padrão do Space é en-US).

{
  "location": { "en-US": { "latitude": 37.5662, "longitude": 126.9910 } },
  "tags": { "en-US": ["novidade", "edição limitada"] },
  "photo": { "en-US": { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } },
  "photos": { "en-US": [ { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } ] }
}

Propriedades de sistema (sys)

Todo Content guarda as propriedades de sistema comuns no objeto sys. space, contentType, createdBy e updatedBy entram no formato Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

status é um dos 4 valores a seguir.

O objeto publish é um ponteiro que aponta para o estado de publicação. Quando publicado, possui todas as chaves a seguir.

Ao anular a publicação, version, at e by saem do publish, restando apenas firstAt e counter. Se nunca houve publicação, publish é { "counter": 0 }.

O objeto archive existe apenas quando arquivado. Quando arquivado, possui version (o sys.version no momento do arquivamento), at (momento do arquivamento) e by (o usuário que arquivou); quando não está arquivado, a própria chave archive não está presente.

O sys.version e todos os valores de momento no exemplo abaixo são os valores no momento real da chamada, e variam a cada chamada.

Publicação, versão e concorrência

O ciclo de vida do Content é o seguinte.

• Ao criar, status é Draft. O Content não é publicado automaticamente na criação. Esse ponto difere do Content Type. O Content Type é publicado automaticamente no momento da criação, mas o Content só entra no caminho de entrega após uma chamada de publicação separada.
• Ao publicar, status passa a Published.
• Ao modificar depois de publicar, status passa a Changed. Significa que há alterações não publicadas.
• Ao anular a publicação, status volta a Draft.
• Para arquivar, é preciso anular a publicação primeiro. Um Content em estado publicado não pode ser arquivado diretamente.

O sys.version sobe 1 a cada alteração.

As requisições de modificação, modificação parcial, publicação, anulação de publicação, arquivamento e desarquivamento devem enviar o sys.version atual no cabeçalho x-weegloo-version. Se esse valor estiver ausente ou divergir da versão atual, é considerado um conflito de modificação concorrente e a requisição é rejeitada. As requisições de criação e exclusão não têm esse cabeçalho. As transições de estado como publicação, anulação de publicação, arquivamento e desarquivamento não têm corpo de requisição separado.

Limites de valor

Além das validations definidas no Content Type, os valores dos campos estão sujeitos ao teto de plataforma que o tipo determina. Os tetos por tipo estão na tabela Tipos de campo do Content Type.

Esse teto é verificado quando se escreve o valor no Content e verificado mais uma vez na publicação. Por meio de size em validations, não é possível informar um valor maior que esse teto. Um Content Type com um valor assim é recusado ao ser salvo (consulte Erros do Content Type). Portanto, um valor ShortText é recusado a partir de 65 caracteres, independentemente de size.

Além dos tetos por tipo, o conjunto dos valores de texto de um Content tem um teto total. O comprimento dos valores dos campos ShortText, LongText e RichText, somado em todos os campos e em todos os Locale, não pode ultrapassar 102.400 caracteres. Por exemplo, se você preencher os valores de cinco Locale de um único campo RichText com 20.480 caracteres cada, só isso já leva o total a 102.400 caracteres. Os valores dos campos Json e Array não são incluídos nesse total. Esse total é verificado na criação, na modificação e na modificação parcial. Na modificação parcial, o total é calculado sobre o resultado completo, com a modificação já aplicada, incluindo os campos que não foram alterados.

As validations têm momentos de verificação diferentes conforme o item. unique, mediaMimetypeGroup, mediaImageDimensions, mediaFileSize e referContentType são verificados apenas na publicação. Os demais itens, junto com os tetos de tipo e de plataforma, são verificados tanto na escrita quanto na publicação. Portanto, um valor que passou na escrita pode ser recusado na publicação.

Location e Refer não aceitam chaves além das definidas. Se você informar uma chave abreviada como lat ou uma chave desconhecida abaixo de sys, o valor é recusado.

Erros

São os códigos que surgem na validação dos valores dos campos. Os códigos que surgem na publicação, na versão e nas transições de estado ainda não estão reunidos nesta tabela. Para os códigos comuns a todos os recursos, consulte Erros comuns.

API

A URL base de todos os endpoints abaixo é https://cma.weegloo.com/v1, e é necessário um token Bearer que autentique na CMA no cabeçalho Authorization. As operações de modificação, modificação parcial, publicação, anulação de publicação, arquivamento e desarquivamento devem enviar junto o cabeçalho X-Weegloo-Version (o sys.version atual do recurso) para o controle de concorrência otimista.

Ao filtrar ou ordenar a lista plana (GET /spaces/{spaceId}/contents) por fields.*, você deve indicar também o Content Type com sys.contentType.sys.id={contentTypeId}. A forma contentType={contentTypeId} não o substitui. O caminho /content-types/{contentTypeId}/contents já tem o Content Type explícito no caminho, portanto não é preciso indicá-lo separadamente.

Documentos relacionados

• Content Type: o gabarito deste Content (definição de campos, apiName).
• CDA Content: entrega o Content publicado aos visitantes (leitura).
• Tag: rótulo de classificação aplicado em metadata.tags.
• Multilíngue (conceito): Locale padrão, preenchimento obrigatório, fallback.