Referência da API

Esta referência é a especificação da HTTP API para desenvolvedores que lidam diretamente com o WEEGLOO a partir do código. O bloco de endpoint de cada página de recurso é renderizado como um console no qual você preenche você mesmo o caminho, os cabeçalhos e o corpo e o chama de verdade. Ali mesmo é possível verificar como a requisição se parece e em que formato a resposta retorna.

O agente de IA não chama esta HTTP API diretamente, e sim usa as ferramentas MCP do WEEGLOO. A especificação a seguir destina-se aos casos em que o código de uma aplicação, como frontend, backend ou scripts, chama a API diretamente.

API e Base URL

O WEEGLOO oferece várias APIs divididas conforme a finalidade. Escolha a Base URL correspondente à API que você vai chamar. Não adivinhe nem altere o host.

Os caminhos têm como base /v1/.... Por exemplo, a lista de Content dentro de um Space é https://cma.weegloo.com/v1/spaces/{spaceId}/contents.

Identidade e tokens

No WEEGLOO há dois sistemas de identidade completamente separados entre si. A API que se pode chamar é determinada por qual identidade emitiu o token.

O Weegloo User é uma conta da plataforma WEEGLOO. Ao fazer login pela primeira vez (por exemplo, com login social), a conta é criada ali mesmo (o primeiro login já é o cadastro). No entanto, para lidar com o conteúdo de um Space específico, é preciso ser membro desse Space, e a participação é definida pelo convite de alguém que já pertence a ele e pela atribuição de um SpaceRole. Ou seja, a conta em si pode ser criada livremente, mas o acesso a cada Space e o que se pode fazer nele são controlados pela participação e pelo papel. O Bearer token dessa identidade (um PersonalAccessToken para servidor e CI, ou o token recebido ao fazer login no estúdio de conteúdo) autentica CMA, Upload e CDA. Para a entrega pública exposta no navegador, em vez do token use um DeliveryAccessToken (CDA) com permissões reduzidas ao mínimo.

O ServiceUser é um end-user que se cadastrou no produto (cadastro feito via ServiceLogin). A quem o cadastro fica aberto e se o cadastro novo exige aprovação de um administrador são definidos pela configuração do ServiceLogin. O Bearer token dessa identidade (emitido em auth.weegloo.com) autentica ACMA, ACDA e Upload. Não pode ser usado em CMA nem CDA.

Os tokens não cruzam as fronteiras de identidade. Não se deve enviar um token de ServiceUser para CMA ou CDA, e o token de Weegloo User não é um chamador válido em ACMA ou ACDA. A única superfície compartilhada pelas duas identidades é o Upload, e o lugar onde o Media é criado depois do upload se divide conforme a identidade: CMA (Weegloo User) ou ACMA (ServiceUser).

Convenções comuns

As quatro a seguir não se limitam a um recurso específico e se aplicam em comum a todas as chamadas. Cada página de recurso pressupõe essas convenções e trata apenas do que lhe é próprio.

• Propriedades do sistema (sys): a estrutura dos metadados sys de todos os recursos (id, version, Refer e status de publicação).
• Parâmetros de query comuns: consulta de lista (limit, order, filter) e paginação baseada em cursor.
• Convenções: tipo de mídia da resposta, edição parcial (JSON Patch) e controle de concorrência (X-Weegloo-Version).
• Erros: formato da resposta de erro e códigos comuns.

Referência de recursos

As especificações de recursos por API são tratadas nos hubs a seguir.

• CMA: modelo e gestão de conteúdo: Content Type, Content, Media, Tag, Locale e recursos de gestão como tokens, organização, Space, papéis, Webhook, WebHosting e ServiceLogin.
• CDA: entrega: entrega de conteúdo publicado em modo somente leitura.
• Upload: enviar arquivos e receber o Upload a ser usado na criação de Media e WebHosting.
• Auth: login OAuth e troca de tokens de ServiceUser.
• ACMA: gestão de conteúdo dos membros do app (ServiceUser).
• ACDA: entrega de conteúdo publicado aos membros do app (ServiceUser).