API Reference

This reference is the HTTP API specification for developers who work with WEEGLOO directly from code. The endpoint block on each resource page renders as a console where you can fill in the path, headers, and body and actually call the API. You can see right there what a request looks like and what shape the response comes back in.

An AI agent does not call this HTTP API directly; it uses the WEEGLOO MCP tools instead. The specifications below are for when application code such as a frontend, backend, or script calls the API directly.

APIs and Base URLs

WEEGLOO provides several APIs divided by purpose. Pick the Base URL that matches the API you are calling. Do not guess or alter the host.

Paths are based on /v1/.... For example, the list of Content in a Space is https://cma.weegloo.com/v1/spaces/{spaceId}/contents.

Identity and tokens

WEEGLOO has two completely separate identity systems. Which API you can call is determined by the identity that issued the token.

A Weegloo User is a WEEGLOO platform account. The account is created on the spot the first time you sign in (for example through social login), so your first login is your signup. To work with the content of a particular Space, however, you have to be a member of that Space, and membership is set by an invitation from someone already in it together with a SpaceRole assignment. In other words, anyone can freely create the account, but which Space you can enter and what you can do there is controlled by membership and roles. This identity's Bearer token (a PersonalAccessToken for servers and CI, or the token received from content studio login) authenticates CMA, Upload, and CDA. For public delivery exposed to a browser, use a least-privilege DeliveryAccessToken (CDA) instead of the token.

ServiceUser is an end-user who signed up for the product (signing up through ServiceLogin). Who signup is open to, and whether new signups require administrator approval, are determined by the ServiceLogin settings. This identity's Bearer token (issued by auth.weegloo.com) authenticates ACMA, ACDA, and Upload. It cannot be used with CMA or CDA.

Tokens do not cross identity boundaries. A ServiceUser token must not be sent to CMA or CDA, and a Weegloo User token is not a valid caller on ACMA or ACDA. The one surface the two identities share is Upload: after the upload, the place where the Media is created splits by identity, going to CMA (Weegloo User) or ACMA (ServiceUser).

Common conventions

The four items below are not specific to any one resource; they apply to every call. Each resource page assumes these conventions and covers only its own content.

• System properties (sys): The structure of the sys metadata on every resource (id, version, Refer, publish status).
• Common query parameters: List queries (limit, order, filter) and cursor-based pagination.
• Conventions: The response media type, partial updates (JSON Patch), and concurrency control (X-Weegloo-Version).
• Errors: The error response format and common codes.

Resource reference

The resource specifications per API are covered in the hubs below.

• CMA: content modeling and management: Content Type, Content, Media, Tag, Locale, and management resources such as tokens, organizations, Space, roles, Webhook, WebHosting, and ServiceLogin.
• CDA: delivery: Read-only delivery of published content.
• Upload: Upload a file to get an Upload to use for creating Media and WebHosting.
• Auth: ServiceUser OAuth login and token exchange.
• ACMA: Content management for app members (ServiceUser).
• ACDA: Delivery of published content to app members (ServiceUser).