Die Kommunikation mit dem Content Management Server über die XML-Schnittstelle findet mit Payloads statt. Payloads enthalten Anfragen (Requests) und Antworten (Responses). Für jede Anfrage in einem Payload wird genau eine Antwort im Ergebnis-Payload erzeugt.
<cm-request ...>
<obj-create>
<name>simplePub</name>
<parent>/</parent>
<objClass>publication</objClass>
</obj-create>
</cm-request>
Der obige Request, der eine Datei unmittelbar unterhalb des Basisordners anlegt, führt zu folgender Response:
<cm-response ...>
<cm-code numeric="0" phrase="ok">
<obj>
<id>32191</id>
</obj>
</cm-code>
</cm-response>
Bei Anfragen, mit denen Parameterwerte von Instanzen mit where und folgendem get ermittelt werden sollen, gibt die Struktur der Anfrage die Struktur der Antwort vor. Eine Anfrage ist gewissermaßen eine Schablone, die der Content Management Server ausfüllt, um die Antwort zu erzeugen. Im folgenden Beispiel gibt der Request vor, dass die Response den Namen und die ID der selektierten Dateien enthalten soll.
<cm-request ...>
<obj-where>
<objClass>document</objClass>
</obj-where>
<obj-get>
<name/>
<id/>
</obj-get>
</cm-request>
Das Antwort-Dokument zu diesem Request wird eine Response enthalten, in der für jede auf das obj-where-Element passende Datei der Name und die ID geliefert werden:
<cm-response ...>
<cm-code numeric="0" phrase="ok">
<obj>
<name>mary</name>
<id>92674</id>
</obj>
</cm-code>
<cm-code numeric="0" phrase="ok">
<obj>
<name>john</name>
<id>72941</id>
</obj>
</cm-code>...
</cm-response>
In den beiden vorausgehenden Beispiel-Responses ist zu erkennen, dass für jede in der Anfrage mit where selektierte Instanz ein cm-code-Element erzeugt wird. Innerhalb eines solchen Elements sind die abgefragten Parameterwerte je Instanz als Inhalt des Klassennamenelements kodiert. In den obigen Beispielen ist dies das obj-Element.
Manche Parameterwerte sind Referenzen auf Instanzen der gleichen oder einer anderen Klasse. So ist beispielsweise die übergeordnete Datei (parent) eines Ordners (außer beim Basisordner) eine Referenz auf eine Vorlage. Die Mitglieder (users) einer Benutzergruppe (group) sind Benutzer-Referenzen, und die obligatorischen Felder (mandatoryAttributes) einer Vorlage (objClass) sind Referenzen auf Felder (attribute). Wie später gezeigt wird, können die Instanzen, auf die sich die Referenzen beziehen, durch eine Erweiterung der Abfrage-Schablone im gleichen get-Aufruf ebenfalls nach Werten ihrer Parameter befragt werden.
Hier folgt jedoch zunächst ein Beispiel, das zeigt, wie die im Basisordner enthaltenen Dateien abgefragt und in der Antwort kodiert werden:
<cm-request ...>
<obj-where>
<path>/</path>
</obj-where>
<obj-get>
<children/>
</obj-get>
</cm-request>
Die Antwort hat das folgende Schema:
<cm-response ...>
<cm-code numeric="0" phrase="ok">
<obj>
<children>
<listitem>92674</listitem>
<listitem>72941</listitem>
</children>
</obj>
</cm-code>
</cm-response>
Zurückgegeben werden in diesen Fällen die eindeutigen Identifikatoren der Instanzen, bei Dateien, Versionen, Links und Tasks die IDs, bei den Instanzen aller anderen Klassen die Namen. Ein Identifikator wird nicht als Inhalt des entsprechenden Parameterelements kodiert, d. h. die ID einer Dateireferenz ist nicht der Inhalt eines id-Elements und der Name eines Feldes ist nicht der Inhalt eines name-Elements. Stattdessen werden die Identifikatoren mit listitem als Listenelemente kodiert. Hier ein Beispiel, in dem die Gruppen ermittelt werden, in denen ein Benutzer Mitglied ist. Auf den Request
<cm-request ...>
<user-where>
<login>mustermann</login>
</user-where>
<user-get>
<groups/>
</user-get>
</cm-request>
folgt eine Antwort nach diesem Schema:
<cm-response ...>
<cm-code numeric="0" phrase="ok">
<user>
<groups>
<listitem>cmadmins</listitem>
<listitem>sysadmins</listitem>
</groups>
</user>
</cm-code>
</cm-response>