API-Referenz
Die API macht enneo programmatisch zugänglich. Endpunkte, Methoden und Authentifizierung stehen vollständig in der API-Referenz.
Zur API-ReferenzEnneo verbindet API, SDK und eigenen Code. Entwicklungsteams binden schneller an, bilden eigene Logik ab und automatisieren Prozesse. Enneo passt sich Ihren Prozessen an, nicht umgekehrt.
Drei Wege der Anbindung: API, SDK und eigener Code. Alle drei laufen in einer in Deutschland entwickelten, DSGVO-konformen Plattform mit EU-Hosting.
Sprechen enneo programmatisch an und integrieren es in bestehende Pipelines.
Prüft Einbettung in die Zielarchitektur, Governance, Betriebs- und Sicherheitsmodell.
Bewertet Risiko, Abhängigkeit und Compliance (DSGVO, EU-Hosting).
Die drei Wege unterscheiden sich im Anpassungsgrad. Im Projekt kombinieren Sie sie frei.
Die API macht enneo programmatisch zugänglich. Endpunkte, Methoden und Authentifizierung stehen vollständig in der API-Referenz.
Zur API-ReferenzDas enneo SDK bindet Funktionen und KI-Agenten an und reduziert den Integrationsaufwand.
Eigener Code bildet kundenindividuelle Logiken und Abläufe ab, die über die Standardkonfiguration hinausgehen.
Enneo ist in Deutschland entwickelt, DSGVO-konform und wird in der EU gehostet.
Mehr zu Datenschutz und Sicherheit steht auf unserer DSGVO-Seite
Schritt 1
API-Referenz und SDK-Dokumentation prüfen, Integrationsziele mit der Zielarchitektur abgleichen.
Schritt 2
Standardanbindung über API und SDK aufsetzen, enneo an bestehende Systeme anschließen.
Schritt 3
Eigenen Code einbringen, wo die Standardkonfiguration nicht ausreicht.
Schritt 4
Governance, DSGVO und Betriebsmodell klären, Rollen und Verantwortung festlegen.
Schritt 5
Produktiv nehmen und iterativ auf weitere Prozesse ausweiten.
Wie enneo Kanäle und Systeme insgesamt verbindet, zeigt die Übersicht Integrationen und Architektur
Alle Angaben zu Authentifizierung, Rate Limits und Endpunkten stehen in der API-Referenz. Wir führen sie bewusst nur an einer verbindlichen Stelle, damit sie aktuell bleiben.
Im technischen Architektur-Gespräch gleichen wir Ihre Zielarchitektur mit API, SDK und eigenem Code ab. Danach folgen Anbinden, Erweitern, Absichern und Skalieren.
Sprach- und Methodenabdeckung stehen verbindlich in der SDK-Dokumentation. Wir führen diese Angaben nur an einer Stelle, damit sie aktuell bleiben.
Wenn die Standardkonfiguration eine projektspezifische Logik nicht abbildet. Passende Szenarien gehen wir im Architektur-Gespräch durch.
Nein. Offene API und dokumentiertes SDK integrieren enneo in Ihre bestehende Landschaft, statt sie zu binden.
Die Authentifizierungsverfahren stehen in der API-Referenz. Jeder Zugriff läuft innerhalb der Rechte, die Sie festlegen.
Rollenbasierte Rechte begrenzen jeden Zugang auf freigegebene Daten und Aktionen. Enneo protokolliert jeden Zugriff nachvollziehbar.
Das hängt von der Produktstufe ab. Copilot+: Schreiben nur mit Freigabe. Autopilot: vollautomatisch innerhalb der Berechtigungen, die Sie festlegen. Enneo protokolliert jede Aktion nachvollziehbar.
Angaben zur Versionierung stehen in der API-Referenz. Wir führen sie nur an einer verbindlichen Stelle, damit sie aktuell bleiben.
Fehlercodes und Retry-Verhalten stehen in der API-Referenz. Events und Webhooks ergänzen die asynchrone Verarbeitung.
Formate und Payload-Strukturen stehen verbindlich in der API-Referenz. Wir führen diese Angaben nur an einer Stelle, damit sie aktuell bleiben.
Testbetrieb und Abnahme legen wir im Architektur-Gespräch fest. Sie starten mit einem Prozess, nicht mit der gesamten Landschaft.
Das SDK bindet Funktionen und KI-Agenten an. Die Methoden stehen in der SDK-Dokumentation.
Eigener Code reagiert auf Events und führt API-Aufrufe an Drittsysteme aus. Details stehen auf der Seite Events und Webhooks.
Umfang, Betrieb und Verantwortung legen wir im Projekt fest. Rollen und Verantwortung klären wir im Schritt Absichern.
Bei komplexen oder risikoreichen Fällen entscheidet ein Mensch (Human-in-the-Loop). Die KI-Agenten eskalieren an Ihr Team.