Schnellstart

Kurzantwort: Sie brauchen drei Dinge: die Basis-URL der API, ein Zugriffstoken und den API-Pfad Ihres Modells. Damit steht der erste Request in fünf Minuten. Alle komplexen Lesevorgänge laufen über POST, weil die Anfrage einen Körper braucht — das ist die wichtigste Umgewöhnung gegenüber üblichen REST-APIs.

---

Was Sie vorher haben müssen

	Beispiel	woher
Basis-URL	https://api.example.com/api/rest	vom Betreiber
Token-Endpunkt	https://id.example.com/realms/<realm>/protocol/openid-connect/token	vom Betreiber
Zugangsdaten	Client-ID, ggf. Secret	vom Betreiber
API-Pfad des Modells	/crm/customer	aus dem Modell bzw. der OpenAPI-Beschreibung

Schritt 1: Token holen

Für einen technischen Zugang (Server-zu-Server) genügen Client-Credentials:

curl -s -X POST \
  "https://id.example.com/realms/<realm>/protocol/openid-connect/token" \
  -d grant_type=client_credentials \
  -d client_id=<client-id> \
  -d client_secret=<secret>

Antwort (gekürzt):

{ "access_token": "eyJhbGciOi…", "expires_in": 300, "token_type": "Bearer" }

Für Anwendungen mit angemeldeten Benutzern nehmen Sie stattdessen den Authorization-Code-Flow — siehe Bearer-Token und Kontext.

Schritt 2: Ein Objekt anlegen

curl -X POST "https://api.example.com/api/rest/crm/customer/create" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "data": { "name": "Muster GmbH", "email": "info@muster.de" },
        "response": ["id", "name"]
      }'

{
  "data": { "id": "5a2b8f1e-…", "name": "Muster GmbH" },
  "meta": { "error": false, "errorMessage": null, "notNull": false }
}

Zwei Dinge fallen sofort auf:

1. Das eigentliche Objekt steckt in data, nicht auf oberster Ebene.
2. response ist Pflicht. Sie sagen darin, welche Felder Sie zurückbekommen wollen — steht dort nichts, ist der Request ungültig (400).

Schritt 3: Lesen

curl -X POST "https://api.example.com/api/rest/crm/customer/read/5a2b8f1e-…" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "response": ["+"] }'

+ steht für „alle einfachen Felder”. Für einen schnellen Blick geht auch GET /read/{id} ohne Körper — das liefert immer * (alle Felder plus Referenzen mit ID).

Schritt 4: Suchen

curl -X POST "https://api.example.com/api/rest/crm/customer/query" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "response": ["id", "name"],
        "parameter": {
          "limit": 25,
          "page": 0,
          "order": [{ "field": "name", "order": "ASC" }],
          "query": {
            "type": "AND",
            "filter": [{ "key": "name", "value": "Muster", "param": "LIKE" }]
          }
        }
      }'

{
  "data": [{ "id": "5a2b8f1e-…", "name": "Muster GmbH" }],
  "meta": { "totalCount": 1, "currentPage": 0, "currentPageSize": 25, "currentLimit": 25 }
}

Schritt 5: Ändern

curl -X PATCH "https://api.example.com/api/rest/crm/customer/update/5a2b8f1e-…" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "data": { "id": "5a2b8f1e-…", "email": "neu@muster.de" },
        "response": ["+"]
      }'

PATCH ändert nur, was Sie nennen. PUT dagegen beschreibt den kompletten Zielzustand — was dort fehlt, wird geleert. Der Unterschied ist die häufigste Fehlerquelle beim Einstieg, siehe Daten schreiben.

Das Grundmuster jeder Anfrage

flowchart LR
    A["Token im Header<br/>Authorization: Bearer …"] --> B["POST auf den Endpunkt"]
    B --> C["Körper:<br/>data · response · parameter"]
    C --> D["Antwort:<br/>data + meta"]

Baustein	wofür
data	das Objekt, das geschrieben wird (bei Schreiboperationen)
response	welche Felder die Antwort enthält — immer erforderlich
parameter	Filter, Sortierung, Seitengröße (bei Listen)
exclude	einzelne Felder aus einer Wildcard herausnehmen

Wie geht es weiter?

• Bearer-Token und Kontext — Token besorgen, erneuern, Mandant wechseln
• Was von außen möglich ist — welche Operationen ein Modell hat
• Daten lesen — response richtig einsetzen
• Suchen und Blättern — Filter und Pagination