Skip to main content
A Cativa organiza conteúdo numa hierarquia de quatro níveis. Entender essa hierarquia é essencial para saber qual endpoint chamar e o que pode ser criado por API versus o que é configurado pelo admin no painel.

A hierarquia

Cada tenant tem uma única Comunidade (o “site” inteiro do cliente). Dentro dela, o admin cria múltiplos Espaços, cada um com seus próprios Grupos. Os Grupos contêm Posts, Comentários e, opcionalmente, Cursos.
A diferença entre Espaço e Grupo é fácil de lembrar: Espaço é a divisão temática que aparece na navegação principal; Grupo é onde a conversa acontece e onde as permissões via badge são aplicadas.

Quem cria o quê

A regra geral: estrutura é tarefa do admin, conteúdo é tarefa do parceiro.
Endpoints de criação de Espaço, Grupo e Curso existem mas exigem escopo administrativo. Chaves de parceiro com escopo padrão (recomendado) não enxergam essa categoria. Peça ao admin do tenant para criar a estrutura no painel: esse é o fluxo natural. As seções de escrita abaixo assumem uma chave com escopo administrativo.

Controle de acesso: badge libera grupo

Cada Grupo pode exigir um ou mais badges para o usuário entrar. Isso é configurado no painel, na tela de acesso de cada grupo:
O parceiro não configura essa regra (ela vive no admin), mas dispara a transição: ao atribuir um badge ao usuário, ele ganha acesso automático a todos os grupos que aceitam aquele badge. Veja Badges como permissão.

Endpoints de leitura

Mesmo sem criar estrutura, você quase sempre precisa ler grupos: para mostrar ao usuário no seu app ou para descobrir IDs antes de criar posts.

Listar grupos

GET /community/groups retorna uma lista paginada. Aceita filtros por espaço e paginação.
Resposta ilustrativa (paginada):
Os JSON desta página são ilustrativos. O schema autoritativo campo a campo fica na aba API Reference (tag Group).

Detalhe de um grupo

GET /community/groups/{groupId} traz o grupo completo, incluindo allowedBadges (os badges que liberam entrada) e as flags do próprio usuário (isInGroup, isModerator).

Listar membros

GET /community/groups/{groupId}/members retorna os membros paginados, com role, flag de moderador e data de expiração do acesso (quando houver).

CRUD de grupo (escopo administrativo)

Criar um grupo

Resposta ilustrativa (201 Created):
allowedBadges no create já amarra o grupo aos badges que liberam entrada, sem precisar do painel. Combine com a atribuição de badge para automatizar acesso ponta a ponta.

Membros: entrar, sair, convidar e remover

Entrar e sair

O join respeita o controle de acesso: se o grupo exige um badge que o usuário não tem, retorna 403.

Convidar e remover

Convide por email quando você só tem o email; use userId quando já resolveu o usuário.

Preenchimento em massa

Para popular um grupo de uma vez, sem convidar um por um:
add/by-allowed-badges adiciona todos os usuários que já têm algum dos allowedBadges do grupo. É a forma de “reconciliar” o grupo depois de configurar os badges.

Expiração por membro

Defina uma data em que o acesso daquele membro expira automaticamente:

Criar posts e comentários

Posts ficam dentro de um Grupo. Você precisa do groupId antes: pegue pela listagem ou guarde no onboarding.
O autor do post é sempre o usuário associado à credencial autenticada. Não é necessário (nem permitido) enviar authorId no body.
O usuário associado à credencial precisa ter acesso ao grupo (pelo menos um badge compatível, ou pertencer ao grupo aberto). Sem acesso, retorna 403 forbidden. Para comentar, poste em POST /community/posts/{postId}/comments:
Mesma regra de acesso: o usuário precisa poder ver o post.

Erros comuns

O usuário não tem um badge que libere o grupo. Atribua o badge certo antes (veja Badges como permissão) ou confirme que o grupo é aberto.
O grupo não existe naquele tenant, ou é secreto e não aparece na descoberta. Confirme o groupId na listagem.
Criar/editar/excluir grupo e adicionar em massa exigem escopo administrativo. Peça a credencial certa ao admin do tenant.

Antipattern: um grupo por cliente via API

Não modele “um grupo por cliente”. Grupos são entidades estáticas definidas pelo admin: representam comunidades de discussão, não containers efêmeros. Para personalizar acesso por cliente, use badges: crie um único grupo “VIP Members” e atribua o badge Premium aos clientes certos.

Próximos passos

Badges como permissão

Como usar badges para liberar acesso sem criar estrutura nova.

Webhooks

Receba eventos quando posts são criados, usuários entram em grupos, etc.