Konfigurierte Datenstrecken statt Skript-Friedhof.

Die fertigen Anbindungen decken die Systeme ab, die fast jeder hat: Buchhaltung, Kalender, Postfach, Team-Chat, Bank-Import. Welche das genau sind, steht auf der Seite Integrationen & Webhooks. Der Integrations-Hub ist für den Rest da, also für den Lieferanten-Feed, das Bestellportal deines größten Kunden, das Branchensystem, das außer dir kaum jemand einsetzt. Beides greift ineinander: Die Zugangsdaten deiner selbst gebauten Strecken liegen in derselben verschlüsselten Ablage wie die der fertigen Anbindungen.

Nein, aber ehrlich gesagt solltest du wissen, wie eine Schnittstelle grundsätzlich funktioniert. Du klickst Bausteine zusammen und füllst Felder aus, es gibt keine Programmiersprache im Bauplan. Was du brauchst, ist die Doku des Fremdsystems und ein Gefühl dafür, welches Feld wohin gehört. Wer schon einmal einen CSV-Import gemappt hat, kommt zurecht. Wer noch nie mit einer Schnittstelle zu tun hatte, sollte die erste Strecke mit uns zusammen bauen.

Für Verbindungen, an denen Octibiz beteiligt ist: in den meisten Fällen ja. Es gibt keine Gebühr pro Ausführung, die Daten bleiben auf deiner Instanz, und du bekommst ein Journal statt einer Zeile im Aktivitätsprotokoll. Was der Hub nicht hat, ist ein Katalog mit tausenden vorkonfigurierten Anbietern. Wenn du zwei Fremdsysteme ohne Octibiz-Bezug verbinden willst, ist ein Dritt-Dienst weiterhin das passendere Werkzeug.

Rückgängig machen im Sinne eines Undo-Knopfes: nein. Was du hast, ist Nachvollziehbarkeit und mehrere Bremsen davor. Vor dem Aktivieren prüft das System den Bauplan und listet offene Punkte auf. Der Testlauf läuft durch denselben Ablauf wie der Echtbetrieb und landet im Journal. Interne Schreibvorgänge laufen über den regulären Weg mit Rechten, Prüfung und Audit-Eintrag, sind also genauso rückverfolgbar wie eine Eingabe von Hand. Und Pflichtfelder in einer Zuordnung brechen laut ab, statt einen halb gefüllten Datensatz anzulegen.

Der Zugriff nach innen ist an einen benannten Benutzer gebunden: Eine Integration schreibt nur mit dessen Rechten und dessen Marken-Sicht, und ohne diese Angabe verweigert der Baustein die Arbeit. Nach außen werden Ziel-Adressen gegen interne Netze geprüft, Umleitungen sind abgeschaltet, Antwortgrößen gedeckelt. Zugangsdaten liegen verschlüsselt in der Integrations-Ablage und nie im Bauplan, weil sie sonst im Export, im Journal und in jedem Backup stünden. Eingehende Aufrufe werden signaturgeprüft, und eine Webhook-Strecke ohne hinterlegtes Geheimnis lässt sich gar nicht erst aktivieren.

Das sind vier getrennte Rechte: lesen, bauen und ändern, ausführen und wiederanlaufen lassen sowie die Inhalte im Journal sehen. Die Trennung ist Absicht, denn im Journal stehen echte Nutzdaten. Deine Entwicklerin darf bauen, der Support darf Läufe ansehen und wiederholen, aber nicht zwangsläufig jeden Datensatz lesen. Das ganze Modul lässt sich außerdem komplett abschalten, dann sind auch die Ansichten nicht erreichbar.

Ja, über den Bündel-Export. Die Datei enthält den Bauplan, die benutzten Feld-Zuordnungen und deren Tabellen. Sie enthält bewusst nicht das Webhook-Geheimnis, den ausführenden Benutzer und den Aktiv-Zustand. Nach dem Einlesen ist die Integration also inaktiv, und du setzt beides im Editor. Zweimal dieselbe Datei einzulesen ergibt eine Integration und nicht zwei.