Keine Funktion nur in der Oberfläche: 100 % API.
UI, Automationen, KI und Integrationen sind bei Octibiz Clients derselben versionierten REST-API: 2.168 Operationen, vollständig OpenAPI-dokumentiert. Was du klicken kannst, kannst du auch aufrufen. Ohne Ausnahme, ohne Hintertür.
API-First im laufenden System. Im Grundpaket enthalten, nicht zubuchbar.
Auf einen Blick
- Was es ist
- Jede Oberflächen-Aktion ist ein dokumentierter REST-Aufruf
- Zuordnung
- Im Grundpaket enthalten
- Buchbar
- nicht einzeln. Jede Instanz bringt sie mit
- Für wen
- alle Betriebe, unabhängig davon, ob der Zusatz Handel gebucht ist
- Betrieb
- Auf dem eigenen Server des Kunden oder von uns in Deutschland betrieben. Eine isolierte Instanz je Kunde, eigene Datenbank.
Kommt dir das bekannt vor?
Die "API" ist ein Feigenblatt
Viele Tools bieten eine API, aber nur für ein Zehntel der Funktionen. Der Rest existiert nur in der Oberfläche. Sobald du automatisieren oder integrieren willst, stößt du an die Wand: "Das geht leider nur manuell."
UI und API verhalten sich unterschiedlich
Was die Oberfläche validiert, lässt die API durch. Oder umgekehrt. Rechteprüfungen, die im Frontend greifen, fehlen an der Schnittstelle. Solche Hintertüren sind Integrations-Bugs und Sicherheitsrisiken zugleich.
Doku aus dem letzten Jahr
Handgepflegte API-Dokumentation veraltet mit jedem Release. Du entwickelst gegen eine Beschreibung, die mit der Realität nur noch verwandt ist.
Im Fundament
Was API-First leistet
Eine API für alles: 2.168 Operationen
Jede Fähigkeit von Octibiz ist eine Operation der zentralen REST-API unter /api/v1, vom Lead über Angebot, Projekt, Zeit und Ticket bis zu Faktura, Lager und Versand. 2.168 Operationen decken das komplette System ab, weil es architektonisch keine "Nur-UI-Funktion" geben darf: Die Mitarbeiter-Oberfläche selbst arbeitet ausschließlich über diese API.
OpenAPI-Dokumentation: generiert, nicht gepflegt
Die vollständige OpenAPI-Spezifikation wird automatisch aus dem System erzeugt. Sie kann gar nicht veralten. Damit funktionieren Standard-Werkzeuge sofort: interaktive Referenz, Client-Generatoren, Contract-Tests, Postman-Import.
Saubere Fehler: RFC 7807 statt Rätselraten
Fehler kommen strukturiert zurück: maschinenlesbar nach RFC 7807 (Problem Details), mit Status, Typ und feldgenauen Verletzungen. Fehlermeldungen sind übersetzbar (Deutsch/Englisch). Es ist dieselbe saubere Fehlerbehandlung, die auch die Oberfläche nutzt.
Rechte & Marken-Scope identisch zur UI: keine API-Hintertür
Die API kennt keine Sonderrechte: Jeder Aufruf durchläuft exakt dieselbe Rechteprüfung wie ein Klick in der Oberfläche: feingranulare Berechtigungen, Marken-Abgrenzung und objektbezogene Zugriffskontrolle auf jeder einzelnen Operation. Ein Token kann nie mehr als der Nutzer, dem es gehört.
Webhooks & Ereignisse: das System meldet sich bei dir
Für den Weg nach draußen musst du nicht pollen: Ausgehende Webhooks liefern Ereignisse signiert an deine Endpunkte; eingehende Webhooks werden signaturgeprüft entgegengenommen. Der zugrunde liegende Ereignis-Katalog ist derselbe, den auch die Automation nutzt, öffentlich dokumentiert.
Stabile IDs & Versionierung: Integrationen, die halten
Öffentliche Objekt-IDs sind stabile, sortierbare Kennungen nach dem ULID-Standard, keine fortlaufenden Zahlen, die Rückschlüsse erlauben oder bei Migrationen brechen. Die API ist unter /api/v1 versioniert und wird abwärtskompatibel weiterentwickelt: Neues kommt dazu, Bestehendes bricht nicht.
Alle Funktionen im Überblick
21 Einzelfunktionen, nach Bereichen sortiert. Aufklappen, was dich interessiert.
Abdeckung (4 Funktionen)
- 2.168 REST-Operationen
- Vollständige Systemabdeckung: jede Fähigkeit als Operation unter /api/v1.
- UI = API-Client
- Die Mitarbeiter-Oberfläche und das Kundenportal arbeiten ausschließlich über diese API.
- Verwaltungs-API
- Rollen, Einstellungen, Automationen, Webhooks, Plugins per API steuerbar.
- Plugin-Erweiterung
- Aktivierte Module/Plugins erweitern die API automatisch um ihre Operationen.
Dokumentation (4 Funktionen)
- OpenAPI-Spezifikation
- Automatisch generiert, immer aktuell; Grundlage für Referenz und Tooling.
- Interaktive Referenz
- Durchsuchbare Doku mit Beispielen unter octibiz.com/doku.
- Client-Generierung
- Standard-OpenAPI-Generatoren für deine Zielsprache nutzbar.
- MCP-Werkzeug-Katalog
- KI-Werkzeuge werden aus derselben OpenAPI-Quelle erzeugt (siehe KI und MCP).
Qualität & Verhalten (5 Funktionen)
- RFC-7807-Fehler
- Strukturierte Problem-Details mit feldgenauen Verletzungen.
- Mehrsprachige Fehler (de/en)
- Fehlermeldungen folgen dem Sprach-Header.
- Serverseitige Listen
- Pagination, Sortierung, Filter auf Collections.
- Stabile IDs (ULID)
- Öffentliche, sortierbare, nicht-erratbare Objekt-Kennungen.
- Versionierung /api/v1
- Additive Weiterentwicklung, dokumentierte Garantien, öffentliches Changelog.
Sicherheit (5 Funktionen)
- Identische Rechteprüfung
- Feingranulare Berechtigungen + objektbezogene Prüfung wie in der UI.
- Marken-Scope serverseitig
- Markenbezogene Daten nur im erlaubten Scope.
- Token-Auth
- Kurzlebige Tokens + Refresh; getrennte Kontexte intern/Portal/Verwaltung.
- Rate-Limits
- Schutz der Auth- und API-Strecken.
- Audit je Schreiboperation
- Akteur (Mensch/Automation/KI), Vorher/Nachher, Request-Trace.
Ereignisse (3 Funktionen)
- Ausgehende Webhooks
- Signierte Zustellung mit Wiederholung; Ziel-Schutzprüfung.
- Eingehende Webhooks
- Signaturgeprüfte Entgegennahme.
- Ereignis-Katalog
- 188 dokumentierte fachliche Ereignisse (Stand Juli 2026).
Was darauf steht
Welche Module API-First tragen
Diese Fähigkeit arbeitet nicht für sich, sondern in jedem Modul, das du benutzt, ohne sie nachzubauen.
KI & MCP
Der MCP-Server exponiert die API-Operationen als KI-Werkzeuge: dieselben Rechte, derselbe Audit-Trail, automatisch vollständig.
Automation
Jede API-Operation ist Automations-Aktion; der Ereignis-Katalog liefert die Auslöser.
Rollen & Rechte
Tokens tragen die Rechte ihres Nutzers: feingranular, je Marke, objektbezogen geprüft.
Integrationen & Webhooks
Fertige Anbindungen (lexoffice, DATEV, Google, Slack, Banken …) nutzen dieselbe API-Infrastruktur wie deine eigenen.
Audit & DSGVO
Jede schreibende API-Aktion ist auditiert. Die Antwort auf "Wer hat das geändert?" schließt Integrationen ein.
Entwickler-Hub
Plugin-SDK und Erweiterungs-Doku, wenn API und Webhooks nicht reichen und du im System selbst erweitern willst.
Automation, API und KI
API-First und die KI
Die KI ruft dieselben Operationen auf wie die Oberfläche, unter denselben Rechten.
KI-Assistent · eingetippt
"Zeig mir die OpenAPI-Operation zum Anlegen von Zeitbuchungen und ein Beispiel-Payload." Die KI liest die generierte Spezifikation und liefert ein lauffähiges Beispiel.
Automationen, die du damit baust
- Wenn im Shop-System eine Bestellung eingeht (dein Webhook → Octibiz-API) → lege den Auftrag an und reserviere den Bestand.
- Wenn in Octibiz eine Rechnung festgeschrieben wird → pushe das Ereignis per Webhook an dein BI-/Data-Warehouse.
- Nächtlicher Abgleich: Dein Skript synchronisiert Stammdaten aus einem Bestandssystem über die API, mit denselben Validierungen wie die UI.
Die KI bedient das ganze System unter denselben Rechte-, Marken- und Audit-Regeln wie ein Mensch. Von außen über MCP anbindbar, in der App direkt bedienbar, beides aus demselben Funktionsumfang.
Klare Kante
Wofür du etwas anderes brauchst
Die Grenzen des Fundaments, bevor du sie im Betrieb findest.
Kein GraphQL-Endpunkt
Die Schnittstelle ist REST mit OpenAPI-Beschreibung. Ein zweiter Schnittstellen-Stil ist nicht geplant.
Browser-Bootstrap außerhalb des API-Katalogs
SSO-Redirects, Binär-Downloads und öffentliche Formular-/Webhook-Empfänger erscheinen bewusst nicht als API-Operationen. Sie sind Transport, keine Fachlichkeit.
Kein anonymer Zugriff
Jede Operation erfordert einen authentifizierten Kontext mit Rechten, auch lesend. Das ist Absicht (DSGVO, Mandantenschutz), keine Einschränkung, die wir aufweichen werden.
Häufige Fragen zu API-First
Ist wirklich jede Funktion per API verfügbar?
Jede fachliche Fähigkeit: ja, das erzwingt die Architektur, denn UI, Automation und KI sind Clients derselben API. Bewusste Ausnahmen sind wenige Browser-Strecken, die technisch keine API-Operationen sind (Login-Redirects beim SSO, Binär-Downloads, öffentliche Formular-Empfänger); deren fachliche Pendants sind als API-Operationen vorhanden.
Wie stabil ist die API? Muss ich Breaking Changes fürchten?
Die API ist unter /api/v1 versioniert und wird additiv weiterentwickelt: Neue Operationen und Felder kommen hinzu, Bestehendes bleibt kompatibel. Änderungen sind über das öffentliche Changelog nachvollziehbar; ein Versionswechsel wäre ein neuer Einstiegspunkt, kein stiller Bruch.
Gibt es fertige Client-SDKs?
Wir setzen auf den OpenAPI-Standard statt auf handgepflegte SDKs: Aus der stets aktuellen Spezifikation generierst du mit Standard-Tooling typsichere Clients für praktisch jede Sprache. Für Erweiterungen im System gibt es zusätzlich ein Plugin-SDK (siehe Entwickler-Hub).
Wie authentifiziere ich Maschinen-Zugriffe, und was dürfen sie?
Per Token (kurzlebig, mit Refresh) im Kontext eines Nutzers. Der Zugriff kann exakt so viel wie dieser Nutzer, inklusive Marken-Abgrenzung. Für Integrationen empfiehlt sich eine dedizierte Identität mit minimaler Rolle; jede Aktion erscheint im Audit-Trail.
Was ist mit Rate-Limits und Massen-Operationen?
Auth- und API-Strecken sind rate-limitiert, Listen sind serverseitig paginiert. Die Plattform bleibt auch unter Integrationslast stabil. Für Massen-Synchronisation nutzt du Pagination plus Filter; sprich uns bei Migrationsszenarien an, wir beraten zum effizienten Vorgehen.
Kann ich per API auch verwalten: Rollen, Automationen, Einstellungen?
Ja. Auch die Verwaltungs-Ebene ist API: Rollen und Rechte, Einstellungen, Automations-Regeln, Webhooks und selbst die Plugin-Verwaltung sind reguläre Operationen, natürlich hinter den entsprechenden Verwaltungs-Rechten.
Warum REST und kein GraphQL?
Bewusste Entscheidung: eine versionierte REST-API mit OpenAPI-Spezifikation ist maximal werkzeug- und standardfreundlich (Client-Generatoren, Contract-Tests, MCP-Ableitung) und für ein System mit klaren Ressourcen die robusteste Wahl. Feld-Auswahl, Filter und Pagination decken die typischen GraphQL-Argumente ab.
Prüf uns nach: Die vollständige API-Referenz ist öffentlich. Vergleiche sie mit dem, was dein aktueller Anbieter "API" nennt.
Dreißig Minuten am laufenden System, mit Prüfprotokoll statt Folien. Was dich an diesem Dienst interessiert, schauen wir uns zuerst an.
