Was du klicken kannst, kannst du auch aufrufen.
Oberfläche, Kundenportal, Automation und KI sind Clients derselben versionierten REST-API mit 2.168 API-Operationen. Es gibt keine Funktion, die nur in der Oberfläche existiert.
Aus dem laufenden System, nicht nachgebaut.
Auf einen Blick
- Umfang
- 2.168 API-Operationen unter /api/v1
- Dokumentation
- OpenAPI, aus dem System erzeugt. Sie kann nicht veralten
- Fehler
- RFC 7807 mit feldgenauen Verstößen, auf Deutsch und Englisch
- Identifikatoren
- ULID, stabil und sortierbar. Keine fortlaufenden Zahlen
- Für Agenten
- MCP-Server, Werkzeug-Katalog automatisch aus der Spezifikation
- Erweitern
- Plugin-Werkzeuge mit fertiger Modulvorlage, SPI 3.27
Die Wege rein
Womit willst du arbeiten?
Sechs Zugänge, eine Wahrheit darunter. Alle prüfen dieselben Rechte und schreiben in dasselbe Protokoll.
REST-API
2.168 API-Operationen unter /api/v1, versioniert und additiv weiterentwickelt. Auch Verwaltung geht per API: Rollen, Einstellungen, Automationen, Webhooks und die Plugin-Verwaltung selbst.
Mehr dazuOpenAPI-Spezifikation
Hier zum Herunterladen, 2.168 Operationen, erzeugt aus dem laufenden System statt von Hand gepflegt. Damit funktionieren Standardwerkzeuge sofort: interaktive Referenz, Client-Erzeugung für deine Sprache, Vertragstests, Import in deine Werkzeugkette. Der Umfang ist ungefiltert und zeigt auch Operationen von Modulen, die du nicht gebucht hast; welche deine Instanz ausliefert, zeigt sie selbst unter /api/docs.
Mehr dazuMCP-Server für Agenten
Der Werkzeug-Katalog wird aus derselben Spezifikation erzeugt, lesend und schreibend. Dein Agent bekommt keine Sonderschnittstelle, sondern dieselben Operationen unter den Rechten der Identität, die du ihm gibst.
Mehr dazuPlugin-SDK
Wenn API und Webhooks nicht reichen, baust du im System selbst: eigene Objekte, eigene Ansichten, eigene Operationen. Installation zur Laufzeit per Archiv oder über Composer, ohne den Kern zu forken.
Mehr dazuWebhooks in beide Richtungen
Ausgehende Ereignisse gehen signiert an deine Endpunkte, mit Zustellwiederholung und einer Prüfung, die interne Adressen ausschließt. Eingehende Aufrufe nehmen wir signaturgeprüft entgegen. Ein Webhook braucht bei uns keine Sonderrechte.
Mehr dazuKommandozeile für den Betrieb
Aktualisieren, prüfen, zurückrollen, Module erzeugen und Instanzen einrichten laufen als Kommandos. Damit passt Octibiz in deine Automatisierung, statt sie zu erzwingen.
Mehr dazuWie binde ich einen KI-Agenten an Octibiz an?
Über den eingebauten MCP-Server deiner Instanz, dessen Werkzeug-Katalog automatisch aus der OpenAPI-Spezifikation entsteht und der die Rechte der Identität erbt, die du dem Agenten gibst. Die Einstiegspunkte:
- Beschreibung für LLMs
- https://octibiz.com/llms.txt
- Volltext für LLMs
- https://octibiz.com/llms-full.txt
- API-Referenz
- https://octibiz.com/doku/referenz/referenz/api
- OpenAPI
- https://octibiz.com/api/openapi.json
- MCP-Server
- stdio, vom Client gestartet
- Ereignis-Katalog
- https://octibiz.com/doku/referenz/referenz/events
- Release-Historie
- https://octibiz.com/doku/referenz/referenz/releases
Der MCP-Endpunkt gehört zu deiner Instanz, nicht zu dieser Website. Zugriff geht nur mit authentifiziertem Kontext, auch lesend. Anonyme Aufrufe gibt es nicht, und daran ändern wir nichts.
Ohne Anmeldung geht nichts
Der erste Aufruf
JSON Web Token am Authorization-Kopf, Rolle ROLE_API. Fehlt das Recht für eine Operation, antwortet sie mit 403, auch wenn der Token gilt.
curl -H "Authorization: Bearer $TOKEN" \
-H "Accept: application/json" \
https://deine-instanz.example/api/v1/customersGET /api/v1/customers
Kunden auflisten
POST /api/v1/customers
Kunden anlegen
GET /api/v1/customers/{ulid}
Einen Kunden lesen
Drei von 2.168. Fehler kommen als RFC 7807 (application/problem+json), Identifikatoren sind
ULID: Sortierbar nach Entstehungszeit und ohne zentrale Vergabe erzeugbar. Wer Daten aus zwei Instanzen zusammenführt, bekommt keine Kollision. Vollständige Referenz mit allen Bereichen.
Für KI-Agenten
MCP-Server anbinden
Kein HTTP-Endpunkt: Der Server spricht stdio, dein Client startet den Prozess. Drei generische Werkzeuge reichen für alle 2.168 Operationen.
# Token erzeugen, mit Laufzeit und Namen
php bin/console auth:mcp-token mcp@deine-firma.de --ttl 7 --name "Claude Desktop"
# Der Client startet den Server selbst, mit diesen zwei Variablen
MCP_API_BASE_URL=... MCP_API_TOKEN=...
php mcp/bin/server.php- list_operations
- describe_operation
- invoke_operation
Ein Token übt die Rechte seines Benutzers aus, auch der Agent. Er kann nichts, was der zugehörige Mensch nicht auch könnte, und jede Schreibaktion steht mit Urheber-Art im Protokoll. Vollständige Anbindungsanleitung, Werkzeug-Katalog.
In beide Richtungen
Webhooks
Verwaltet über die API selbst, geschützt vom Recht platform.webhook.manage. Welche Ereignisse es gibt, liefert der Katalog als Endpunkt, nicht als Liste in einer PDF.
- GET /api/v1/webhook-event-catalog
- GET /api/v1/webhooks
- POST /api/v1/webhooks
- GET|PATCH|DELETE /api/v1/webhooks/{ulid}
Der Ereignis-Katalog trennt die Veto-Punkte, an denen ein Plugin einen Vorgang noch anhalten kann, von den reinen Meldungen danach. Ereignis-Katalog ansehen.
Häufige Fragen von Entwicklerinnen und Entwicklern
Ist wirklich jede Funktion per API verfügbar?
Jede fachliche Fähigkeit, ja. Die Architektur erzwingt es, weil Oberfläche, Automation und KI Clients derselben API sind. Ausgenommen sind ein paar Browser-Strecken, die technisch keine Operationen sind: Weiterleitungen beim Anmelden über ein Identitätssystem, Binärdownloads und öffentliche Formular-Empfänger. Deren fachliche Gegenstücke existieren als Operationen.
Plattform-Dienst im DetailMuss ich Brüche fürchten?
Die API ist versioniert und wird additiv weiterentwickelt. Neue Operationen und Felder kommen dazu, Bestehendes bleibt kompatibel. Ein Versionswechsel wäre ein neuer Einstiegspunkt, kein stiller Bruch. Änderungen stehen im öffentlichen Changelog.
Zur Release-HistorieGibt es fertige SDKs für meine Sprache?
Wir pflegen keine SDKs von Hand, sondern setzen auf den OpenAPI-Standard. Aus der stets aktuellen Spezifikation erzeugst du dir mit Standardwerkzeugen einen typsicheren Client für praktisch jede Sprache. Für Erweiterungen im System gibt es zusätzlich das Plugin-SDK.
Plugin-System im DetailWie authentifiziere ich einen Dienst, und was darf er?
Mit einem JSON Web Token am `Authorization`-Kopf; die Rolle `ROLE_API` ist Voraussetzung. Ein Token übt die Rechte seines Benutzers aus, nicht mehr. Fehlt das Recht für eine Operation, antwortet sie mit 403, auch wenn der Token gilt. Der Token übt die Rechte seines Benutzers aus, inklusive Marken-Abgrenzung. Für Integrationen legst du am besten eine eigene Identität mit minimaler Rolle an, jede schreibende Aktion erscheint im Protokoll. Ohne Anmeldung erreichbar sind ausschließlich die Token-Strecken des Kundenportals. Alles andere verlangt einen Token.
Warum REST und nicht GraphQL?
Bewusste Entscheidung. Eine versionierte REST-API mit OpenAPI ist maximal werkzeugfreundlich: Client-Erzeugung, Vertragstests und die Ableitung des KI-Werkzeug-Katalogs hängen daran. Feldauswahl, Filter und seitenweises Abrufen decken die üblichen GraphQL-Argumente ab. Ein zweiter Schnittstellenstil ist nicht geplant.
Kann ich Octibiz als Backend für eine eigene Oberfläche nutzen?
Ja. Die mitgelieferte Oberfläche ist Client Nummer eins, nicht der einzige. Wer eine eigene Anwendung darauf setzt, benutzt dieselben Operationen und erbt dieselben Rechteprüfungen. Konten legst du per API oder von Hand an. Die automatische Nutzerbereitstellung über SCIM ist in Planung.
Was gilt für Massen-Operationen und Limits?
Die Grenzen stehen in der Konfiguration und nicht im Ermessen: Anmeldung je Konto 10 pro 15 Minuten, Anmeldung je Adresse 30 pro Minute, Anmeldeversuche 5 pro Minute, Öffentliche Formulare 10 pro Minute, Öffentliches Tracking 120 pro Minute. Listen kommen serverseitig seitenweise und lassen sich filtern und sortieren. Für Migrationen sprich uns vorher an, statt dass dein Skript nachts gegen ein Limit läuft.
So fängst du an
Drei Schritte vom ersten Blick in die Referenz bis zum eigenen Modul. Ohne Formular vor der Dokumentation.
- 01
Referenz lesen
Die API-Referenz und die OpenAPI-Spezifikation sind öffentlich, ohne Anmeldung. Du siehst jede Operation, bevor du mit uns sprichst.
- 02
Entwickler-Instanz anfragen
Schreib uns über das Kontaktformular oder an info@octibiz.com, was du bauen willst. Du bekommst in der Regel am nächsten Werktag eine Antwort, und wir klären den Zugang zu einer Instanz zum Entwickeln.
- 03
Gerüst erzeugen
Das Plugin-SDK legt dir per Kommando das Gerüst für ein eigenes Modul an: eigene Objekte, eigene Oberfläche, eigene API-Operationen, ohne den Kern zu forken.
Prüf uns an der Referenz nach
Die API-Referenz ist öffentlich. Vergleich sie mit dem, was dein aktueller Anbieter API nennt. Das ist der ehrlichste Test, den wir dir anbieten können. Du willst Octibiz selbst nutzen statt darauf zu bauen? Zum Founding-Programm für Kunden.
