Content

Content ist ein einzelner konkreter Datensatz, der mit einem Content Type (der Vorlage) erzeugt wird. Am Beispiel eines Bekleidungs-Onlineshops: Der Content Type "Produkt" legt den Aufbau der Angaben wie Produktname, Preis und ausführliche Beschreibung fest, und "Stainless Tumbler 500ml" ist ein einzelner Content, der dieser Vorlage folgt.

Content besteht aus zwei Teilen. In fields stehen die tatsächlichen Werte der einzelnen Felder, in sys der Zustand wie Veröffentlichung, Version und Archivierung. In der CMA ist Content eine Unterressource von Space: Für Abruf und Löschen dient der Pfad /spaces/{spaceId}/contents, für Erstellung und Änderung der unter Content Type liegende Pfad /spaces/{spaceId}/content-types/{contentTypeId}/contents. Verwaltungsvorgänge werden in der CMA ausgeführt, und der veröffentlichte Snapshot wird über die CDA ausgeliefert.

Ressourcenstruktur

Im Folgenden steht die Antwort eines Einzelabrufs des veröffentlichten Content "Stainless Tumbler 500ml". Neben sys (Systemattribute) enthält er fields (Feldwerte) und metadata (Zusatzinformationen wie Tags).

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 1,
      "at": "2026-06-18T09:51:44.128Z",
      "firstAt": "2026-06-18T09:51:44.128Z",
      "counter": 1,
      "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
    },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:51:14.597Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:51:44.128Z",
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "price": { "en-US": 18000 },
    "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

Wichtige Schlüssel:

• sys.id: Eindeutige Kennung des Content. Sie wird im {contentId} der Pfade für Einzelabruf, Änderung, Löschung und Veröffentlichung eingesetzt.
• sys.contentType: Ein Refer, der auf den Content Type verweist, dem dieser Content folgt.
• fields: Die Werte der einzelnen Felder. Der Schlüssel ist der apiName des Felds, der Wert ist eine Zuordnung je Locale. Erläutert unter Der Feldschlüssel ist der apiName.
• metadata.tags: Liste der Tag, die an diesen Content gehängt sind. Jeder Eintrag hat die Form Refer<Tag>; sind keine Tags vergeben, ist es ein leeres Array [].

Der Feldschlüssel ist der apiName

Der Schlüssel des fields-Objekts ist der apiName des jeweiligen Felds. Es ist nicht die interne id des Content Type und nicht der im Content-Studio angezeigte Feldname (z. B. Produktname). Beim Erstellen oder Lesen eines Content muss daher der im Content Type definierte apiName als Schlüssel verwendet werden.

Die Felder des Demo-Content Type "Produkt" und ihre apiName-Zuordnung sind wie folgt.

Jeder Feldwert ist eine Zuordnung je Locale. Die Form des Werts hängt von localized ab.

• Ein Feld mit localized: true kann in der Form { "<locale>": Wert } Werte für mehrere Locales enthalten. Beispiel: "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }.
• Ein Feld mit localized: false (nicht lokalisiertes Feld) erhält nur einen Wert unter dem Schlüssel der Standard-Locale des Space. Andere Locale-Schlüssel sind nicht zulässig. Da die Standard-Locale des Demo-Space en-US ist, hat der Preis nur den einen Schlüssel en-US, etwa "price": { "en-US": 18000 }.

Welche Locale die Standard-Locale ist, bis zu welcher Locale ein required-Feld ausgefüllt werden muss und welche Fallback-Regeln gelten, wenn kein Wert vorhanden ist, wird unter Mehrsprachigkeit (Konzept) behandelt.

Wertform je Typ

Die Form des Werts innerhalb eines Locale-Schlüssels richtet sich nach dem type des Felds. Die meisten Typen nehmen den Wert dieses Typs unverändert auf (Texttypen einen String, Number und Long eine Zahl, Boolean true/false). Die Typen, deren Form ein Objekt oder ein Array ist und die deshalb leicht zu Verwechslungen führen, sind die folgenden.

• Location: ein Objekt der Form { "latitude": <Zahl>, "longitude": <Zahl> }. latitude liegt zwischen -90 und 90, longitude zwischen -180 und 180; beide Schlüssel sind erforderlich. Außer den definierten Schlüsseln werden keine weiteren akzeptiert, weshalb verkürzte Schlüssel wie lat, lng oder lon zurückgewiesen werden.
• Refer: ein Refer-Objekt, das auf das Ziel verweist; es wird nicht nur ein id-String, sondern das sys-Objekt unverändert eingesetzt. Verweist es auf einen anderen Content, ist targetType gleich Content, verweist es auf ein Media, gleich Media. Die Refer-Form selbst wird unter Die Refer-Form bei den Systemattributen (sys) definiert.
• Array: ein JSON-Array, das Werte des Elementtyps enthält. Sind die Elemente Text, ist es ein Array von Strings; sind die Elemente Refer (Content oder Media), ist es ein Array von Refer-Objekten. Es ist kein Array von id-Strings.

Im Folgenden stehen Beispiele für die Werte innerhalb von fields (wenn die Standard-Locale des Space en-US ist).

{
  "location": { "en-US": { "latitude": 37.5662, "longitude": 126.9910 } },
  "tags": { "en-US": ["Neuheit", "Limitierte Auflage"] },
  "photo": { "en-US": { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } },
  "photos": { "en-US": [ { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } ] }
}

Systemattribute (sys)

Jeder Content führt die gemeinsamen Systemattribute im sys-Objekt. space, contentType, createdBy und updatedBy haben die Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }).

status ist einer der folgenden vier Werte.

Das publish-Objekt ist ein Zeiger auf den Veröffentlichungszustand. Im veröffentlichten Zustand enthält es alle folgenden Schlüssel.

Beim Zurückziehen entfallen aus publish die Schlüssel version, at und by, und es bleiben nur firstAt und counter. Wurde noch nie veröffentlicht, ist publish gleich { "counter": 0 }.

Das archive-Objekt existiert nur im archivierten Zustand. Im archivierten Zustand enthält es version (die sys.version zum Zeitpunkt der Archivierung), at (Archivierungszeitpunkt) und by (archivierende Person); ist die Ressource nicht archiviert, fehlt der Schlüssel archive vollständig.

Die sys.version und alle Zeitwerte im folgenden Beispiel sind die Werte zum tatsächlichen Aufrufzeitpunkt und unterscheiden sich von Aufruf zu Aufruf.

Veröffentlichung, Version und Nebenläufigkeit

Der Lebenszyklus eines Content ist wie folgt.

• Beim Erstellen ist status gleich Draft. Content wird beim Erstellen nicht automatisch veröffentlicht. Darin unterscheidet er sich vom Content Type. Ein Content Type wird mit der Erstellung automatisch veröffentlicht, ein Content gelangt jedoch erst durch einen separaten Veröffentlichungsaufruf in den Auslieferungsweg.
• Beim Veröffentlichen wird status zu Published.
• Wird nach der Veröffentlichung geändert, wird status zu Changed. Das bedeutet, dass nicht veröffentlichte Änderungen vorliegen.
• Beim Zurückziehen wird status wieder zu Draft.
• Zum Archivieren muss zuerst zurückgezogen werden. Ein veröffentlichter Content kann nicht direkt archiviert werden.

sys.version erhöht sich bei jeder Änderung um 1.

Bei Anfragen zum Ändern, Teiländern, Veröffentlichen, Zurückziehen, Archivieren und Dearchivieren muss die aktuelle sys.version im Header x-weegloo-version mitgesendet werden. Fehlt dieser Wert oder weicht er von der aktuellen Version ab, wird dies als Konflikt durch gleichzeitige Änderung gewertet und die Anfrage abgelehnt. Anfragen zum Erstellen und Löschen haben diesen Header nicht. Zustandsübergänge wie Veröffentlichen, Zurückziehen, Archivieren und Dearchivieren haben keinen eigenen Anfragetext.

Wertgrenzen

Für Feldwerte gilt neben den im Content Type hinterlegten validations auch eine vom Typ festgelegte Plattformobergrenze. Die Obergrenzen je Typ finden Sie in der Tabelle Feldarten des Content Type.

Diese Obergrenze wird beim Schreiben eines Wertes in einen Content geprüft und beim Veröffentlichen ein weiteres Mal. Für size in validations lässt sich kein Wert über dieser Obergrenze eintragen. Ein Content Type mit einem solchen Eintrag wird beim Speichern abgelehnt (siehe Fehler bei Content Type). Daher wird ein ShortText-Wert unabhängig von size ab 65 Zeichen abgelehnt.

Zusätzlich zu den Obergrenzen je Typ gilt für die Textwerte eines Content insgesamt eine Obergrenze für ihre Summe. Die über alle Felder und alle Locale addierten Wertlängen der Felder vom Typ ShortText, LongText und RichText dürfen zusammen 102.400 Zeichen nicht überschreiten. Füllen Sie zum Beispiel ein einziges RichText-Feld in fünf Locale mit jeweils 20.480 Zeichen, erreicht die Summe allein dadurch 102.400 Zeichen. Die Werte von Json- und Array-Feldern fließen nicht in diese Summe ein. Diese Summe wird beim Erstellen, Ändern und Teiländern geprüft. Beim Teiländern wird die Summe über das gesamte Ergebnis nach der Änderung berechnet, einschließlich der Felder, die nicht geändert wurden.

Die validations werden je nach Eintrag zu unterschiedlichen Zeitpunkten geprüft. unique, mediaMimetypeGroup, mediaImageDimensions, mediaFileSize und referContentType werden nur beim Veröffentlichen geprüft. Die übrigen Einträge sowie die Typ- und Plattformobergrenzen werden sowohl beim Schreiben als auch beim Veröffentlichen geprüft. Ein Wert, der das Schreiben bestanden hat, kann daher beim Veröffentlichen abgelehnt werden.

Location und Refer akzeptieren nur die definierten Schlüssel. Ein abgekürzter Schlüssel wie lat oder ein fremder Schlüssel unterhalb von sys führt zur Ablehnung.

Fehler

Dies sind die Codes aus der Validierung der Feldwerte. Codes aus Veröffentlichung, Version und Zustandsübergängen sind in dieser Tabelle noch nicht erfasst. Codes, die allen Ressourcen gemeinsam sind, finden Sie unter Gemeinsame Fehler.

API

Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Header Authorization ist ein Bearer-Token erforderlich, das sich gegenüber der CMA authentifiziert. Beim Ändern, Teiländern, Veröffentlichen, Zurückziehen, Archivieren und Dearchivieren muss zur optimistischen Nebenläufigkeitskontrolle zusätzlich der Header X-Weegloo-Version (die aktuelle sys.version der Ressource) gesendet werden.

Wenn Sie die flache Liste (GET /spaces/{spaceId}/contents) nach fields.* filtern oder sortieren, müssen Sie sie zusätzlich mit sys.contentType.sys.id={contentTypeId} auf einen Content Type eingrenzen. Ein bloßes contentType={contentTypeId} ersetzt dies nicht. Der Pfad je Content Type (/content-types/{contentTypeId}/contents) trägt ihn bereits, sodass er dort nicht nötig ist.

Verwandte Dokumente

• Content Type: Die Vorlage dieses Content (Felddefinition, apiName).
• CDA Content: Auslieferung des veröffentlichten Content an Besucher (Lesen).
• Tag: Klassifizierungslabel, das an metadata.tags gehängt wird.
• Mehrsprachigkeit (Konzept): Standard-Locale, Pflichtfüllung, Fallback.