ACDA (App Content Delivery API)

Zuletzt aktualisiert: 22. Juni 2026

Die ACDA (App Content Delivery API) ist eine schreibgeschützte API, die veröffentlichte Content und Media an die im Produkt registrierten Mitglieder, also an ServiceUser, ausliefert. Sobald die betreibende Seite eines Space Inhalte veröffentlicht hat, lesen die Mitglieder dieses veröffentlichte Material über die ACDA aus. Sie können sich die ACDA als die ServiceUser-Variante dessen vorstellen, was die CDA für öffentliche Besucher leistet, nur mit der Mitgliederidentität ausgeführt: Auslieferung veröffentlichter Inhalte. Die ACDA besitzt ausschließlich Abruf-Endpunkte (GET); Erstellen, Ändern und Löschen fallen in die Zuständigkeit der ACMA.

ACDA-Aufrufe verwenden ein von ServiceLogin ausgestelltes Bearer-Token. Dieses Token ist nur für ACMA und ACDA gültig und kann nicht für CMA oder CDA verwendet werden (zum Ablauf der Tokenausstellung siehe Auth API).

Unterschiede zur CDA

Die Antwortform der ACDA entspricht der CDA. Sie liefert nur einen Snapshot des veröffentlichten Materials aus (sys enthält ohne version, status und publish lediglich revision, die zum Veröffentlichungszeitpunkt gültige Version), und beim Abruf wird über locale die zu erhaltende Sprache festgelegt. Die Unterschiede zur CDA liegen im Lesebereich und in der Identität.

  • Lesebereich pro Mitglied: Bei der CDA sehen alle, die mit ein und demselben DeliveryAccessToken aufrufen, dieselbe veröffentlichte Menge. Die ACDA gibt nur das zurück, was dem aufrufenden ServiceUser erlaubt ist; was erlaubt ist, richtet sich nach der ServiceUserRole dieses Mitglieds und seiner Zuweisung. Auch die Identität ist eine andere: Die CDA wird mit einem DeliveryAccessToken aufgerufen, die ACDA mit einem von ServiceLogin ausgestellten Mitglieder-Token.

Auch die Art und Weise, über den Query-Parameter locale die zu erhaltende Sprache festzulegen, entspricht der CDA. Geben Sie einen Code wie locale=ko-KR an, werden fields als der eine Wert dieser Locale zurückgegeben (existiert dieser nicht und greift auch kein Fallback, ist er leer oder null); lassen Sie den Parameter weg, erfolgt die Rückgabe auf dieselbe Weise mit der Standard-Locale des Space; geben Sie locale=* an, wird eine Map mit allen Locale-Werten unverändert zurückgegeben. In den ersten beiden Fällen, in denen in einer Sprache zurückgegeben wird, wird der Header x-weegloo-locale mitgeliefert, der die tatsächlich verwendete Locale angibt (bei locale=* wird er nicht mitgeliefert).

Ressourcenstruktur

Im Folgenden sehen Sie die Form, in der die ACDA einen "Produkt"-Content des Demo-Space ausliefert. Es handelt sich um das Ergebnis eines Abrufs mit locale=ko-KR, bei dem jeder Wert in fields als der eine Wert von ko-KR enthalten ist.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "revision": 3
  },
  "fields": {
    "productName": "스테인리스 텀블러 500ml",
    "price": 18000,
    "description": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량."
  }
}

Wichtige Schlüssel:

  • sys.id: Der eindeutige Bezeichner des Content. Er wird im Pfad des Einzelabrufs als {contentId} eingesetzt.
  • sys.type: Die Ressourcenart; für Content ist sie stets "Content".
  • sys.space: Eine Referenz, die auf den Space verweist, zu dem dieser Content gehört.
  • sys.contentType: Eine Referenz, die auf den Content Type verweist, dem dieser Content folgt.
  • sys.revision: Die Version zum Veröffentlichungszeitpunkt. Bei jeder Veröffentlichung wird die zu diesem Zeitpunkt gültige Version hier abgelegt. Da die ACDA die verwaltungsbezogenen Werte version, status und publish nicht enthält, ist revision der einzige Wert, der auf die veröffentlichte Version verweist.
  • sys.createdBy, sys.updatedBy: Werden nur dann eingeschlossen, wenn publishWithAuthor des Content Type aktiviert ist, und verweisen auf Ersteller und Bearbeiter. Im obigen Beispiel ist diese Option deaktiviert, daher wurden beide Schlüssel weggelassen.
  • fields: Enthält den Wert jedes Feldes in der Form { apiName: value }. Anders als die Locale-Map von CMA und ACMA ({ apiName: { locale: value } }) enthält die ACDA nur den einen Wert der abgerufenen locale. Im obigen Beispiel wurde das Titelfoto photo weggelassen, da für die betreffende Locale kein Wert vorliegt.

Auch Media wird in derselben veröffentlichten Auslieferungsform zurückgegeben und enthält in sys nur revision, nicht jedoch version, status und publish. Media lässt die Autoreninformationen (createdBy, updatedBy) stets weg. Auch fields.file von Media wird als das eine Objekt der abgerufenen Locale zurückgegeben.

API

Alle drei Endpunkte sind Abrufe (GET) und legen über den Query-Parameter locale die zu erhaltende Sprache fest (bei einem Code die betreffende Locale, bei Auslassung die Standard-Locale, bei * die vollständige Map - siehe oben).

  • ACMA: Verwaltungs-API, mit der Mitglieder ihre eigenen Inhalte erstellen und bearbeiten.
  • Auth API: Ausstellung des Tokens für ACDA-Aufrufe.
  • ServiceUser-Anmeldung (Konzept): Konfiguration von ServiceLogin, ServiceUserRole und Zuweisung.