Referencia de la API
Última actualización: 3 de julio de 2026
Esta referencia es la especificación de la API HTTP de WEEGLOO para desarrolladores que trabajan con WEEGLOO directamente desde el código. El bloque de endpoint de cada página de recurso se renderiza como una consola en la que puedes rellenar la ruta, las cabeceras y el cuerpo y llamar realmente al endpoint. Ahí mismo puedes comprobar qué forma tiene la solicitud y con qué forma vuelve la respuesta.
Los agentes de IA no llaman a esta API HTTP directamente, sino que usan las herramientas MCP de WEEGLOO. La especificación de abajo está pensada para cuando llamas a la API directamente desde código de aplicación, como el frontend, el backend o scripts.
API y Base URL
WEEGLOO ofrece varias API divididas según su finalidad. Elige la Base URL que corresponda a la API que vas a llamar. No supongas ni modifiques el host.
| API | Finalidad | Base URL |
|---|---|---|
| CMA | Gestión de contenido (el Weegloo User crea, modifica y elimina) | https://cma.weegloo.com |
| CDA | Entrega de contenido publicado (solo lectura, basada en caché) | https://cda.weegloo.com |
| Upload | Subida de archivos | https://upload.weegloo.com |
| ACMA | Gestión de contenido de los miembros de la app (ServiceUser) | https://acma.weegloo.com |
| ACDA | Entrega a los miembros de la app (ServiceUser) (solo lectura) | https://acda.weegloo.com |
| Auth | Inicio de sesión OAuth y tokens de ServiceUser | https://auth.weegloo.com |
Las rutas se basan en /v1/.... Por ejemplo, la lista de Content dentro de un Space es https://cma.weegloo.com/v1/spaces/{spaceId}/contents.
Identidad y tokens
WEEGLOO tiene dos sistemas de identidad completamente separados entre sí. La API que puedes llamar viene determinada por qué identidad emitió el token.
El Weegloo User es una cuenta de la plataforma WEEGLOO. Al iniciar sesión por primera vez con un proveedor social u otro método, la cuenta se crea en ese mismo momento (el primer inicio de sesión equivale al registro). Ahora bien, para trabajar con el contenido de un Space concreto hay que ser miembro de ese Space, y la pertenencia se define mediante la invitación de alguien que ya forma parte de él y la asignación de un SpaceRole. Es decir, la cuenta en sí se crea libremente, pero a qué Space se accede y qué se puede hacer en él se controla con la pertenencia y el rol. El token Bearer de esta identidad (un PersonalAccessToken para servidor o CI, o el token obtenido mediante el inicio de sesión del estudio de contenidos) autentica CMA, Upload y CDA. Para la entrega pública que se expone en el navegador, en lugar del token se usa un DeliveryAccessToken (CDA) con los permisos reducidos al mínimo.
El ServiceUser es un end-user registrado en el producto (el registro se hace mediante ServiceLogin). A quién se le abre el registro y si los nuevos registros requieren la aprobación de un administrador se define en la configuración de ServiceLogin. El token Bearer de esta identidad (emitido en auth.weegloo.com) autentica ACMA y ACDA y Upload. No se puede usar con CMA ni CDA.
Los tokens no cruzan los límites de identidad. No se debe enviar un token de ServiceUser a CMA ni a CDA, y un token de Weegloo User no es un llamante válido de ACMA ni ACDA. La única superficie que ambas identidades comparten es Upload, y el lugar donde se crea el Media tras la subida se bifurca según la identidad: CMA (Weegloo User) o ACMA (ServiceUser).
Convenciones comunes
Las cuatro páginas siguientes no se limitan a un recurso concreto, sino que se aplican en común a todas las llamadas. Cada página de recurso da por supuesto que se siguen estas convenciones y solo trata su contenido propio.
- Propiedades del sistema (sys): la estructura de los metadatos
sysde todos los recursos (id,version,Refer, estado de publicación). - Parámetros de consulta comunes: la consulta de listas (
limit,order,filter) y la paginación basada en cursor. - Convenciones: tipo de medio de la respuesta, modificación parcial (JSON Patch) y control de concurrencia (
X-Weegloo-Version). - Errores: el formato de la respuesta de error y los códigos comunes.
Referencia de recursos
La especificación de recursos por API se trata en los hubs de abajo.
- CMA: modelado y gestión de contenido: Content Type, Content, Media, Tag y Locale, además de recursos de gestión como tokens, organización, Space, roles, Webhook, WebHosting y ServiceLogin.
- CDA: entrega: entrega de solo lectura del contenido publicado.
- Upload: subir archivos y obtener el Upload que se usará para crear Media y WebHosting.
- Auth: inicio de sesión OAuth e intercambio de tokens de ServiceUser.
- ACMA: gestión de contenido de los miembros de la app (ServiceUser).
- ACDA: entrega de contenido publicado a los miembros de la app (ServiceUser).
