Weegloo Docs - ACMA (App Content Management API)

L'ACMA (App Content Management API) est l'API qui permet aux membres inscrits à un produit, c'est-à-dire les ServiceUser, de manipuler directement les Content et les Media. Considérez qu'il s'agit des mêmes opérations qu'un Weegloo User effectue sur le contenu via CMA, mais réalisées sous l'identité d'un membre. Avec l'ACMA, un membre crée (Create), lit (Read), modifie (Update) et supprime (Delete) des Content et des Media. La portée autorisée de chaque opération est définie par le ServiceUserRole.

Les appels ACMA utilisent un jeton Bearer émis par ServiceLogin. Ce jeton n'est valide que sur ACMA et ACDA, et ne peut pas être utilisé sur CMA ni CDA (pour le flux d'émission du jeton, voir Auth API). Le Content Type, qui est le modèle que suit un membre, ne se crée ni ne se modifie depuis l'ACMA. Le Content Type est géré par un Weegloo User depuis CMA, et l'ACMA ne dispose d'aucun endpoint de création ni de modification de Content Type.

Différences avec CMA

L'ACMA correspond à CMA, mais en diffère par l'identité, la portée de propriété et le comportement de publication.

Élément	ACMA (ServiceUser)	CMA (Weegloo User)
Identité	ServiceUser inscrit à un ServiceLogin. Les droits sont définis par le ServiceUserRole.	Weegloo User. Les droits sont définis par le SpaceRole.
Portée d'accès	La portée de lecture, de modification et de suppression est définie par le `ServiceUserRole` (de la même manière que la lecture par membre d'ACDA). Si la règle du rôle fixe `createdBy` à `:self`, l'opération concernée se limite aux données que le membre a lui-même créées, ce qui s'applique généralement à la modification et à la suppression. La lecture peut, dans la mesure où le rôle l'autorise, inclure aussi les données d'autres membres.	Manipule l'ensemble des données du Space dans la limite autorisée par le SpaceRole.
Publication à la création	Lorsqu'un Content ou un Media est créé, il est publié immédiatement. Il n'y a pas d'appel de publication séparé.	Un Content, une fois créé, doit faire l'objet d'un appel de publication séparé pour entrer dans le circuit de diffusion.
Publication à la suppression	La suppression entraîne automatiquement une dépublication. Il n'est pas nécessaire de dépublier au préalable.	Les données dans l'état publié sont généralement dépubliées d'abord, puis supprimées.
Profil personnel	Se consulte via `GET /me` (et non `/spaces/{spaceId}/me`).	`GET /me` (le Weegloo User courant).
Content Type	Aucun endpoint de création ni de modification. Le modèle relève de CMA.	Crée, modifie et publie les Content Type.

Un membre dont le ServiceUser.isAdmin vaut true peut, en plus, uniquement supprimer les données d'autres membres. Ce droit s'ajoute aux opérations que le rôle autorise ; il n'augmente pas le droit de modification ni le droit de lecture sur les données d'autres membres. Et même cela n'est possible que dans la limite des opérations qu'autorise le ServiceUserRole de ce membre.

Pour une explication détaillée des comportements ci-dessus (portée de propriété, publication automatique à la création, dépublication automatique à la suppression, portée de isAdmin), voir Connexion ServiceUser (concept).

Mes informations (Me)

GET /me renvoie les informations du ServiceUser propriétaire du jeton courant. Comme avec CMA, on appelle directement /me sans passer par le chemin du Space.

Voici la structure de réponse d'un ServiceUser. Le sys contient l'identité et les informations d'inscription, et le corps contient des propriétés d'affichage telles que nickname et avatarUrl.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ",
    "type": "ServiceUser",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "provider": "google",
    "email": "minji.kim@example.com",
    "createdAt": "2026-06-17T09:12:03.114Z",
    "updatedAt": "2026-06-17T09:12:03.114Z"
  },
  "nickname": "Minji",
  "avatarUrl": "https://lh3.googleusercontent.com/a/example-avatar",
  "enableLogin": true,
  "isAdmin": false
}

Clés principales :

sys.id : identifiant unique du ServiceUser. Le createdBy des Content et Media créés par le membre pointe vers cette valeur.
sys.type : type de ressource ; pour un ServiceUser, c'est toujours "ServiceUser".
sys.space : référence pointant vers le Space auquel ce membre appartient.
sys.provider : fournisseur utilisé pour la connexion (ex. : google).
sys.email : adresse e-mail fournie par le fournisseur de connexion.
nickname : nom d'affichage du membre (obligatoire).
avatarUrl : adresse de l'image de profil (facultatif).
roleOverride : référence pointant vers un autre ServiceUserRole lorsqu'on souhaite appliquer ce rôle à ce seul membre (facultatif). Si non défini, le rôle par défaut du ServiceLogin s'applique.
enableLogin : indique si la connexion est autorisée.
isAdmin : si true, le membre peut supprimer les données d'autres membres (voir Différences avec CMA ci-dessus).

Seuls nickname et avatarUrl peuvent être modifiés. Des valeurs telles que provider, email ou isAdmin ne sont pas modifiées directement par le membre.

Content

Un Content est une donnée individuelle qui suit un modèle appelé Content Type. Pour une boutique de vêtements en ligne, chaque produit qui suit le Content Type « Produit » est un Content. Dans l'ACMA, le membre manipule ses propres Content via un chemin lié au Space et au Content Type (/spaces/{spaceId}/content-types/{contentTypeId}/contents).

Voici un Content « Produit » du Space de démonstration.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 3,
      "at": "2026-06-16T14:35:11.210Z",
      "firstAt": "2026-06-15T15:16:20.180Z",
      "counter": 3,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 4,
    "status": "Published"
  },
  "fields": {
    "price": { "ko-KR": 18000 },
    "description": { "ko-KR": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량." },
    "photo": {},
    "productName": { "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

Clés principales :

sys.id : identifiant unique du Content. Il s'insère dans le {contentId} des chemins de consultation, modification et suppression unitaires.
sys.contentType : référence pointant vers le Content Type que suit ce Content.
sys.status : état de publication. Un Content créé dans l'ACMA est publié immédiatement et revient avec Published.
sys.version : version de la ressource, incrémentée de 1 à chaque modification.
sys.publish : historique de publication (version, at, firstAt, counter, by).
fields : contient la valeur de chaque champ sous la forme { apiName: { locale: value } }. L'exemple ci-dessus contient price, description, photo et productName dans la locale ko-KR. Un champ sans valeur (photo) est un objet vide.
metadata.tags : liste des Tag attachés à ce Content.

La consultation de liste accepte les paramètres de requête standard (limit, skip, next, prev, order, select, include), et la réponse renvoie un tableau items accompagné de links (curseurs de pagination).

Media

Un Media est un fichier-ressource téléversé (image, vidéo, document, etc.). Pour qu'un membre crée un Media, il doit d'abord téléverser le fichier via l'Upload API pour obtenir un Upload, puis insérer le sys.id de cet Upload dans la requête de création du Media. Dans l'ACMA, le Media est lui aussi publié automatiquement dès sa création.

Voici le Media d'une photo de gobelet téléversée dans le Space de démonstration.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGjUMsPV3uU",
    "type": "Media",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-15T15:17:30.825Z",
      "firstAt": "2026-06-15T15:17:30.825Z",
      "counter": 1,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:17:30.589Z",
    "updatedAt": "2026-06-15T15:17:30.825Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "title": { "ko-KR": "스테인리스 텀블러 500ml 정면 컷" },
    "description": { "ko-KR": "흰 배경에서 찍은 텀블러 정면 제품 사진입니다." },
    "file": {
      "ko-KR": {
        "fileName": "tumbler.png",
        "contentType": "image/png",
        "mimeGroups": ["Image"],
        "url": "https://weegloo-media.com/medias/HnQ32YiH/3uU/3trmXRM3RqbgSnifyg7OGjUMsPV3uU/ko-KR/1/tumbler.png",
        "detail": { "size": 50847, "image": { "width": 900, "height": 900 } }
      }
    }
  },
  "metadata": { "tags": [] }
}

Clés principales :

sys.id : identifiant unique du Media. Il s'insère dans le {mediaId} des chemins de consultation et de suppression unitaires, et c'est la valeur vers laquelle pointe un Content lorsqu'il référence une photo.
sys.status : état de publication. Un Media créé dans l'ACMA est publié immédiatement et revient avec Published.
fields.title et fields.description : contiennent le titre et la description de la ressource sous forme de carte de locales (facultatif).
fields.file : informations de fichier par locale (obligatoire). Une fois le traitement terminé, url (adresse de diffusion), mimeGroups et detail (taille, résolution de l'image, etc.) sont renseignés.

Dans la requête de création du Media, le fields.file contient une référence vers l'Upload dans son état avant traitement. Chaque entrée de fichier inclut fileName, contentType, mimeGroups, state et upload ; state vaut toujours "PENDING", et upload contient le sys.id de l'Upload obtenu via l'Upload API. Juste après la création, la plateforme traite le fichier, et une fois le traitement terminé, url et detail sont renseignés comme dans la réponse ci-dessus.

Auth API : flux OAuth pour obtenir le jeton utilisé dans les appels ACMA.
ACDA : API de lecture qui diffuse le contenu publié aux membres.
Connexion ServiceUser (concept) : configuration de ServiceLogin et ServiceUserRole.
Upload API : téléversement de fichier avant la création d'un Media.

ACMA (App Content Management API)

Différences avec CMA

Mes informations (Me)

Consulter mes informations

Modifier mes informations

Content

Consulter la liste des Content

Créer un Content

Consulter un Content

Modifier un Content (remplacement total)

Modifier partiellement un Content (JSON Patch)

Supprimer un Content

Media

Créer un Media

Consulter un Media

Supprimer un Media

Différences avec CMA

Mes informations (Me)

Consulter mes informations

Modifier mes informations

Content

Consulter la liste des Content

Créer un Content

Consulter un Content

Modifier un Content (remplacement total)

Modifier partiellement un Content (JSON Patch)

Supprimer un Content

Media

Créer un Media

Consulter un Media

Supprimer un Media

Documents liés