EINE SCHNELLE,
UNSPEKTAKULÄRE API.
Für Clients ohne MCP ist jede Operation über REST und GraphQL verfügbar. Gleiche Authentifizierung, gleicher Audit-Trail. Bauen Sie den Agent des Monats gegen dieselbe Oberfläche.
UNSPEKTAKULÄR IST EIN FEATURE.
In einem CRM, das von der Oberfläche her gedacht ist, kommt die API meist nach dem Interface. Sie deckt ab, woran jemand gedacht hat, hinkt neuen Funktionen hinterher und verhält sich ein wenig anders als der Bildschirm. Wer integriert, lernt ihre Eigenheiten auf die harte Tour.
Ein Headless CRM hat keine Oberfläche, der die API hinterherhinken könnte. In CMP42 ist die API das Produkt. Dieselben Operationen, die Ihre MCP-Tools ausführen, stehen über REST und GraphQL zur Verfügung — gegen dieselben Models, mit derselben Validierung.
Wir nennen sie bewusst unspektakulär. Vorhersehbare Ressourcen, die Ihrer Ontologie entsprechen. Fehlermeldungen, die sagen, was schiefgegangen ist. Kein verstecktes Verhalten, das nur beim Klicken passiert. Spannend soll sein, was Sie darauf bauen — der Slack-Bot, die interne App, der Agent, den Ihr Team nächsten Monat ausliefert.
DREI SCHNITTSTELLEN. EIN VERTRAG.
Jede Operation, überall
Für Clients ohne MCP ist jede Operation sowohl über REST als auch über GraphQL verfügbar. Sie müssen nie die Schnittstelle wechseln, weil einer eine Funktion fehlt.
Gleiches Authentifizierungsmodell
MCP, REST und GraphQL teilen sich ein Authentifizierungsmodell. Berechtigungen, die auf einer Schnittstelle gelten, gelten auf allen — es gibt keine Hintertür.
Gleicher Audit-Trail
Jeder Schreibvorgang ist versioniert und hält fest, welcher Mensch oder Agent ihn erzeugt hat — ob er von Claude über MCP kam, von einem Slack-Bot über REST oder von Ihrer App über GraphQL.
GLEICHE DATEN. IHRE WAHL DER FORM.
Die Beispiele zeigen dieselbe Aufgabe auf beiden Schnittstellen: die Deals in der Verlängerungsphase finden und anschließend eine Notiz zu einem Unternehmen schreiben.
Mit REST adressieren Sie Ressourcen und nutzen HTTP-Methoden — aus jeder Sprache einfach aufzurufen, mit curl leicht zu debuggen.
Mit GraphQL fragen Sie genau die Felder ab, die Sie brauchen, und folgen typisierten Kanten — dem Owner des Deals, seinem Unternehmen — in einem einzigen Aufruf.
Pfade, Feldnamen und Header-Format sind beispielhaft. Die konkrete API-Referenz erscheint mit der Alpha und wird gemeinsam mit den Design Partnern ausgestaltet.
GET /deals?stage=renewal
Authorization: Bearer <token>
200 OK
{ "data": [
{ "id": "cmp42://deal/…",
"title": "Aspen · Q4-Verlängerung",
"stage": "renewal",
"owner": "cmp42://contact/…" } ] }
POST /companies/<id>/notes
{ "body": "Verlängerungsrisiko: Budgetverantwortung gewechselt …" }
201 Created · written_by: app:slack-botquery RenewalDeals {
deals(stage: "renewal") {
id
title
owner { id name }
company { id name }
}
}
mutation {
writeNoteOnCompany(company: "cmp42://company/…",
body: "Verlängerungsrisiko: …") {
id version writtenBy
}
}MCP, REST ODER GRAPHQL? JE NACH CLIENT.
Faustregel: Entscheidet ein Modell, was als Nächstes aufgerufen wird, nehmen Sie MCP. Entscheidet Ihr Code, nehmen Sie REST oder GraphQL.
| Aspekt | MCP | REST | GraphQL |
|---|---|---|---|
| Ideal für | KI-Agents, die ihren nächsten Schritt selbst wählen | Skripte, Bots und Backend-Dienste mit fester Aufgabe | Apps, die einen bestimmten Ausschnitt des Graphen brauchen |
| Typischer Client | Claude Desktop, Claude Code, Cursor, Cline, eigene Agents mit MCP SDK | Der Slack-Bot Ihres Teams, eine interne Automatisierung, ein Daten-Job | Die interne App oder das Dashboard, das Ihr Entwicklungsteam baut |
| Form eines Aufrufs | Ein Tool-Aufruf mit typisierter Eingabe, z. B. list_deals_at_stage | Eine Ressource plus HTTP-Methode | Eine Abfrage mit verschachtelten Feldern über typisierte Kanten |
| Stärke | Das Modell erkennt Tools und ihre Schemata zur Laufzeit | Aus jeder Sprache nutzbar; einfach zu testen und zu debuggen | Genau das abrufen, was Sie brauchen — nicht mehr |
| Authentifizierung & Audit | Gleich | Gleich | Gleich |
EIN AUTHENTIFIZIERUNGSMODELL. EIN AUDIT-TRAIL.
Gleichwertigkeit heißt nicht nur, dass dieselben Operationen existieren, sondern dass sie gleich geregelt sind. Egal, über welche Schnittstelle eine Anfrage kommt: Sie wird vom selben Modell autorisiert und im selben Audit-Trail protokolliert. Jedes Objekt ist versioniert; jeder Schreibvorgang weist aus, welcher Mensch oder Agent ihn erzeugt hat.
Das zählt an dem Tag, an dem Sie den Agent wechseln. Der Slack-Bot, den Sie abschalten, und der Agent, der ihn ersetzt, hinterlassen dieselbe Art von Protokoll — Ihre Historie bleibt über Tools und Jahre hinweg lesbar.
Die Authentifizierung erfolgt über workspace-scoped Bearer-Tokens: Personal Access Tokens für Menschen und Service Tokens für Agents und Bots, jeweils mit Scopes auf Model-Ebene, sodass ein Token nur die Operationen abdeckt, die er wirklich benötigt. Das Standard-Rate-Limit liegt bei 1000 Anfragen pro Minute pro Token; ein Überschreiten liefert 429 mit Retry-After. Die API ist über den URL-Präfix versioniert (/api/v1/); Breaking Changes bedingen eine neue Major-Version, wobei die vorherige Version mindestens zwölf Monate parallel weiterläuft, bevor sie eingestellt wird.