Référence de l'API

Cette référence est la spécification de l'API HTTP destinée aux développeurs qui manipulent WEEGLOO directement depuis leur code. Le bloc d'endpoint de chaque page de ressource est rendu sous forme de console où vous pouvez renseigner vous-même le chemin, les en-têtes et le corps pour effectuer un véritable appel. Vous y voyez sur place à quoi ressemble une requête et sous quelle forme la réponse revient.

Les agents IA n'appellent pas cette API HTTP directement, ils utilisent les outils MCP de WEEGLOO. La spécification ci-dessous concerne les cas où le code applicatif, tel qu'un frontend, un backend ou un script, appelle l'API directement.

API et Base URL

WEEGLOO fournit plusieurs API réparties selon leur usage. Choisissez la Base URL correspondant à l'API que vous appelez. Ne devinez pas l'hôte et ne le modifiez pas.

Les chemins se basent sur /v1/.... Par exemple, la liste des Content d'un Space est https://cma.weegloo.com/v1/spaces/{spaceId}/contents.

Identité et jetons

WEEGLOO possède deux systèmes d'identité entièrement distincts. L'API que vous pouvez appeler dépend de l'identité qui a émis le jeton.

Un Weegloo User est un compte de la plateforme WEEGLOO. Lorsque vous vous connectez pour la première fois, par exemple via une connexion sociale, le compte est créé à ce moment-là (la première connexion vaut inscription). Toutefois, pour manipuler le contenu d'un Space donné, vous devez être membre de ce Space, et l'appartenance se définit par l'invitation d'une personne qui en fait déjà partie et par l'attribution d'un SpaceRole. Autrement dit, le compte lui-même se crée librement, mais le Space auquel vous accédez et ce que vous pouvez y faire sont contrôlés par l'appartenance et le rôle. Le jeton Bearer de cette identité (un PersonalAccessToken pour les serveurs et la CI, ou le jeton obtenu via la connexion au studio de contenu) authentifie les CMA, Upload et CDA. Pour la diffusion publique exposée au navigateur, utilisez à la place du jeton un DeliveryAccessToken (CDA) dont les autorisations sont réduites au minimum.

Un ServiceUser est un end-user inscrit au produit (inscription via ServiceLogin). C'est la configuration de ServiceLogin qui détermine à qui l'inscription est ouverte et si les nouvelles inscriptions requièrent l'approbation d'un administrateur. Le jeton Bearer de cette identité (émis par auth.weegloo.com) authentifie les ACMA, ACDA et Upload. Il ne peut pas être utilisé pour CMA et CDA.

Les jetons ne franchissent pas la frontière entre identités. Un jeton de ServiceUser ne doit pas être envoyé à CMA et CDA, et un jeton de Weegloo User n'est pas un appelant valide pour ACMA et ACDA. La seule surface partagée par les deux identités est Upload ; après le téléversement, l'endroit où le Media est créé varie selon l'identité, soit CMA (Weegloo User), soit ACMA (ServiceUser).

Conventions communes

Les quatre éléments ci-dessous ne sont pas limités à une ressource particulière et s'appliquent en commun à tous les appels. Chaque page de ressource part du principe que ces conventions sont respectées et ne traite que son contenu propre.

• Propriétés système (sys) : structure des métadonnées sys de toutes les ressources (id, version, Refer, état de publication).
• Paramètres de requête communs : consultation de listes (limit, order, filter) et pagination basée sur le curseur.
• Conventions : type de média des réponses, modification partielle (JSON Patch), contrôle de concurrence (X-Weegloo-Version).
• Erreurs : format des réponses d'erreur et codes communs.

Référence des ressources

La spécification des ressources de chaque API est traitée dans les hubs ci-dessous.

• CMA : modélisation et gestion du contenu : Content Type, Content, Media, Tag, Locale, ainsi que les ressources de gestion telles que les jetons, l'organisation, le Space, les rôles, les Webhook, le WebHosting et le ServiceLogin.
• CDA : diffusion : diffusion en lecture seule du contenu publié.
• Upload : téléverser un fichier pour obtenir un Upload à utiliser dans la création d'un Media ou d'un WebHosting.
• Auth : connexion OAuth et échange de jetons des ServiceUser.
• ACMA : gestion de contenu par les membres de l'app (ServiceUser).
• ACDA : diffusion du contenu publié auprès des membres de l'app (ServiceUser).