Programmatischer Zugriff
MCP ist der Zugang für eigenen Code, der Webhook-Eingang für eingehende Daten. Eine klassische REST-Schnittstelle gibt es bewusst nicht.
Wie fremde Systeme mit der Plattform sprechen — und wie nicht.
Es gibt keine klassische REST-Schnittstelle mit API-Schlüssel. Das ist eine Entscheidung, kein Rückstand: die Tool-Fläche ist die eine Definition dessen, was die Plattform kann, und Oberfläche wie Agenten benutzen dieselbe. Eine parallele REST-Fläche wäre eine zweite Wahrheit, die auseinanderdriftet. Deshalb ist MCP das API — mit dem Vorteil, dass ein Client die Werkzeuge samt Parameter-Schema beim Verbinden selbst ausliest, statt einer abgetippten Endpunkt-Liste zu folgen, die veraltet.
Die kurze Antwort: Für Automatisierung und eigenen Code ist MCP der
Zugang; für eingehende Daten aus Drittsystemen der Webhook-Eingang. Die
Routen der Web-App (/api/app/...) sind kein öffentliches API und lassen
sich von außen nicht nutzen.
1. MCP — der programmatische Zugang
Ein Endpunkt pro Workspace, der die gesamte Tool-Fläche trägt (dieselben Funktionen, die die Oberfläche benutzt):
https://app.cegtec.net/api/mcp/<workspace-mcp-key>Key erzeugen/abrufen: in den Einstellungen des Workspace oder über die Tools
generate_mcp_key / get_mcp_key. Der Key ist workspace-gebunden — er kann
nichts außerhalb dieses Workspace sehen oder verändern.
MCP-Clients gibt es für die meisten Umgebungen (Claude, Claude Code, eigene Skripte, n8n). Die vollständige Tool-Liste müssen Sie nicht nachschlagen: ein MCP-Client fragt sie beim Verbinden selbst ab — jedes Tool liefert Beschreibung und Parameter-Schema mit. Das ist der Grund, warum es hier keine abgetippte Endpunkt-Tabelle gibt, die veralten könnte.
2. Webhook-Eingang für eigene Daten
Der generische Dateneingang — hier schicken Sie Zeilen aus einem beliebigen System (Formular, Zapier, Make, eigenes Backend) in einen Workspace:
POST https://app.cegtec.net/api/webhooks/ingest/<orgId>/<sourceId>Authentifizierung: ein Shared Secret pro Quelle, entweder als Header
x-webhook-secret: <secret> oder als Query-Parameter ?secret=<secret> — die
Query-Variante existiert für No-Code-Werkzeuge, die keine Header setzen können.
Fehlt oder passt das Secret nicht: 401. Ist die Quelle deaktiviert: 403.
Angelegt wird eine solche Quelle über create_webhook_source; dabei entstehen
sourceId und Secret.
Was mit den Daten passiert: sie werden auf die Ontologie gemappt (Firma bzw. Lead) und können einen Workflow auslösen — das ist Teil der Quellen-Konfiguration, nicht des Requests.
3. Rückkanäle der Integrationen
Verbundene Dienste melden Ereignisse zurück — Öffnungen und Antworten aus dem E-Mail-Versand, LinkedIn-Aktivität, Kalenderbuchungen, Abrechnung, Telefonie. Diese Rückkanäle richtet die Plattform ein, sobald Sie eine Integration verbinden. Sie rufen sie nicht selbst auf, und Sie müssen nichts davon konfigurieren.
Jeder Rückkanal prüft die Herkunft der eingehenden Daten (Signatur, Secret oder Token) und ordnet sie dem Workspace zu, zu dem die Integration gehört.
4. Was kein API ist
/api/app/<orgSlug>/... — die Routen der Web-App. Sie sind
session-authentifiziert: sie erwarten das Anmelde-Cookie des Browsers und
prüfen zusätzlich die Herkunft des Requests (Origin-Check). Ein Aufruf mit
curl, aus n8n oder aus eigenem Code schlägt fehl, auch mit gültigem Login —
das ist Absicht und kein Fehler. Für alles Programmatische: MCP (Abschnitt 1).
/api/cron/... und /api/admin/... — interne Betriebsendpunkte,
abgesichert über ein geteiltes Secret. Nicht für Kunden bestimmt.
Bekannte Einschränkungen
- Keine öffentliche REST-Fläche für die Kern-Objekte. Firmen, Leads und Deals sind programmatisch über MCP erreichbar, nicht über HTTP-Endpunkte mit API-Key. Sollte sich das ändern, gehört es hierhin.
- Kein OpenAPI-Schema, da es keine öffentliche REST-Fläche gibt. Die MCP-Tools tragen ihre Parameter-Schemata selbst und sind für Clients auslesbar.