ACMA (App Content Management API)
Zuletzt aktualisiert: 22. Juni 2026
ACMA (App Content Management API) ist die API, mit der Mitglieder, die sich beim Produkt registriert haben, also ServiceUser, Content und Media direkt verwalten. Sie können es sich so vorstellen, dass dieselben Aufgaben, die ein Weegloo User über CMA mit Inhalten ausführt, hier unter der Mitgliederidentität ausgeführt werden. Mitglieder erstellen (Create), lesen (Read), bearbeiten (Update) und löschen (Delete) Content und Media über ACMA. Den erlaubten Umfang jeder Aktion legt die ServiceUserRole fest.
Für ACMA-Aufrufe wird ein Bearer-Token verwendet, das von ServiceLogin ausgestellt wird. Dieses Token ist nur für ACMA und ACDA gültig und kann nicht für CMA oder CDA verwendet werden (zum Ablauf der Token-Ausstellung siehe Auth API). Der Content Type, dem ein Mitglied folgt, wird nicht über ACMA erstellt oder bearbeitet. Content Type wird von einem Weegloo User über CMA verwaltet; in ACMA gibt es keine Endpunkte zum Erstellen oder Bearbeiten eines Content Type.
Unterschiede zu CMA
ACMA entspricht CMA, unterscheidet sich aber in Identität, Eigentumsumfang und Veröffentlichungsverhalten.
| Aspekt | ACMA (ServiceUser) | CMA (Weegloo User) |
|---|---|---|
| Identität | ServiceUser, der sich bei ServiceLogin registriert hat. Die Berechtigungen werden durch die ServiceUserRole festgelegt. | Weegloo User. Die Berechtigungen werden durch die SpaceRole festgelegt. |
| Zugriffsumfang | Den Umfang für Lesen, Bearbeiten und Löschen legt die ServiceUserRole fest (genauso wie das mitgliedsbezogene Lesen in ACDA). Wenn die Rollenregel createdBy auf :self setzt, wird diese Aktion auf die selbst erstellten Daten beschränkt; üblicherweise wird das so auf Bearbeiten und Löschen angewendet. Beim Lesen können je nach Rolle auch Daten anderer Mitglieder einbezogen werden. | Verwaltet die Daten des gesamten Space innerhalb des von der SpaceRole erlaubten Umfangs. |
| Veröffentlichung beim Erstellen | Beim Erstellen von Content und Media erfolgt sofort die Veröffentlichung. Es gibt keinen separaten Veröffentlichungsaufruf. | Content wird erst nach dem Erstellen über einen separaten Veröffentlichungsaufruf in den Auslieferungspfad aufgenommen. |
| Veröffentlichung beim Löschen | Beim Löschen erfolgt automatisch auch die Zurücknahme der Veröffentlichung. Eine vorherige Zurücknahme der Veröffentlichung ist nicht erforderlich. | Veröffentlichte Daten werden in der Regel zuerst aus der Veröffentlichung zurückgenommen und dann gelöscht. |
| Eigenes Profil | Wird über GET /me abgefragt (nicht über /spaces/{spaceId}/me). | GET /me (aktueller Weegloo User). |
| Content Type | Keine Endpunkte zum Erstellen oder Bearbeiten. Die Vorlage liegt im Zuständigkeitsbereich von CMA. | Erstellt, bearbeitet und veröffentlicht Content Type. |
Ein Mitglied, bei dem ServiceUser.isAdmin true ist, darf zusätzlich nur die Daten anderer Mitglieder löschen. Dies ist eine Berechtigung, die zu den von der Rolle erlaubten Aktionen hinzukommt; sie erweitert weder die Bearbeitungs- noch die Leseberechtigung für die Daten anderer Mitglieder. Und auch das ist nur innerhalb des Aktionsumfangs möglich, den die ServiceUserRole dieses Mitglieds erlaubt.
Eine ausführliche Erläuterung der oben genannten Verhaltensweisen (Eigentumsumfang, automatische Veröffentlichung beim Erstellen, automatische Zurücknahme der Veröffentlichung beim Löschen,
isAdmin-Umfang) finden Sie unter ServiceUser-Anmeldung (Konzept).
Meine Informationen (Me)
GET /me gibt die Informationen über den ServiceUser selbst zurück, dem das aktuelle Token zugeordnet ist. Anders als bei CMA wird /me direkt aufgerufen, ohne den Space-Pfad zu durchlaufen.
Im Folgenden ist die Antwortstruktur eines ServiceUser dargestellt. In sys stehen die Identitäts- und Registrierungsinformationen, im Hauptteil stehen Anzeigeattribute wie nickname und 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
}Wichtigste Schlüssel:
sys.id: Eindeutige Kennung des ServiceUser. DascreatedByder von einem Mitglied erstellten Content und Media verweist auf diesen Wert.sys.type: Ressourcenart; bei einem ServiceUser immer"ServiceUser".sys.space: Eine Referenz auf den Space, zu dem dieses Mitglied gehört.sys.provider: Der für die Anmeldung verwendete Anbieter (z. B.google).sys.email: Die vom Anmeldeanbieter bereitgestellte E-Mail-Adresse.nickname: Der Anzeigename des Mitglieds (erforderlich).avatarUrl: Die Adresse des Profilbilds (optional).roleOverride: Eine Referenz auf die Rolle, wenn nur diesem Mitglied eine andere ServiceUserRole zugewiesen werden soll (optional). Wird sie nicht gesetzt, gilt die Standardrolle von ServiceLogin.enableLogin: Gibt an, ob die Anmeldung erlaubt ist.isAdmin: Beitruedarf das Mitglied die Daten anderer Mitglieder löschen (siehe oben Unterschiede zu CMA).
Bearbeitbar sind nur nickname und avatarUrl. Werte wie provider, email und isAdmin werden nicht vom Mitglied selbst geändert.
Content
Content ist ein einzelner Datensatz, der einer Vorlage namens Content Type folgt. Bei einem Bekleidungs-Onlineshop ist jedes einzelne Produkt, das dem Content Type "Produkt" folgt, ein Content. In ACMA verwaltet ein Mitglied seinen eigenen Content über den an Space und Content Type gebundenen Pfad (/spaces/{spaceId}/content-types/{contentTypeId}/contents).
Im Folgenden ist ein "Produkt"-Content des Demo-Space dargestellt.
{
"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": [] }
}Wichtigste Schlüssel:
sys.id: Eindeutige Kennung des Content. Sie wird in das{contentId}der Pfade für Einzelabruf, Bearbeitung und Löschung eingesetzt.sys.contentType: Eine Referenz auf den Content Type, dem dieser Content folgt.sys.status: Der Veröffentlichungsstatus. In ACMA erstellter Content wird sofort veröffentlicht und mitPublishedzurückgegeben.sys.version: Die Ressourcenversion, die mit jeder Änderung um 1 erhöht wird.sys.publish: Der Veröffentlichungsverlauf (version,at,firstAt,counter,by).fields: Enthält den Wert jedes Feldes in der Form{ apiName: { locale: value } }. Das obige Beispiel enthältprice,description,photoundproductNamefür die Localeko-KR. Ein Feld ohne Wert (photo) ist ein leeres Objekt.metadata.tags: Die Liste der Tag, die diesem Content zugeordnet sind.
Die Listenabfrage akzeptiert die Standard-Abfrageparameter (limit, skip, next, prev, order, select, include) und gibt in der Antwort ein items-Array zusammen mit links (Seitencursor) zurück.
Media
Media sind hochgeladene Datei-Assets (Bilder, Videos, Dokumente usw.). Damit ein Mitglied ein Media erstellen kann, lädt es zunächst über die Upload API eine Datei hoch und erhält ein Upload, dessen sys.id es dann in die Anfrage zur Media-Erstellung aufnimmt. Auch Media wird in ACMA mit dem Erstellen automatisch veröffentlicht.
Im Folgenden ist ein Media mit einem Tumblerfoto dargestellt, das in den Demo-Space hochgeladen wurde.
{
"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": [] }
}Wichtigste Schlüssel:
sys.id: Eindeutige Kennung des Media. Sie wird in das{mediaId}der Pfade für Einzelabruf und Löschung eingesetzt und ist der Wert, auf den ein Content verweist, wenn er ein Foto referenziert.sys.status: Der Veröffentlichungsstatus. In ACMA erstelltes Media wird sofort veröffentlicht und mitPublishedzurückgegeben.fields.title,fields.description: Enthalten Titel und Beschreibung des Assets als Locale-Map (optional).fields.file: Die Dateiinformationen je Locale (erforderlich). Nach Abschluss der Verarbeitung werdenurl(Auslieferungsadresse),mimeGroupsunddetail(Größe, Bildauflösung usw.) befüllt.
In fields.file der Media-Erstellungsanfrage wird eine Upload-Referenz im Zustand vor der Verarbeitung aufgenommen. Jeder Dateieintrag enthält fileName, contentType, mimeGroups, state und upload vollständig; state ist immer "PENDING", und in upload wird die sys.id des über die Upload API erhaltenen Upload eingetragen. Unmittelbar nach dem Erstellen verarbeitet die Plattform die Datei, und nach Abschluss der Verarbeitung werden wie in der obigen Antwort url und detail befüllt.
Verwandte Dokumente
- Auth API: Der OAuth-Ablauf zum Ausstellen des für ACMA-Aufrufe verwendeten Tokens.
- ACDA: Die Lese-API, die veröffentlichte Inhalte an Mitglieder ausliefert.
- ServiceUser-Anmeldung (Konzept): Einrichtung von ServiceLogin und ServiceUserRole.
- Upload API: Datei-Upload vor der Media-Erstellung.
