ConnectWiz + API & Webhooks
Live-IntegrationDie API, die wir verkaufen, ist die API, die wir selbst nutzen
Die gesamte Plattform ist in einem einzigen OpenAPI-Vertrag beschrieben, aus dem unser eigenes Panel und unsere Mobile-App generiert werden – keine Schatten-Endpunkte, kein Auseinanderdriften von Doku und Code. Darauf aufgesetzt: Commerce-API-Keys mit klaren Scopes, abgesicherte Webhook-Auslöser und Flows, die Ihre Systeme aufrufen.
Entwickler
Was es genau tut
Ein maßgeblicher Vertrag
Ein einziges OpenAPI-3-Dokument beschreibt die Plattform; unsere eigenen TypeScript-Clients werden daraus generiert – die Doku kann gar nicht von der Wirklichkeit abweichen, weil die Wirklichkeit aus der Doku gebaut wird.
Commerce-API-Keys
Keys, die Sie selbst ausstellen, mit ausdrücklichen Scopes – Katalog lesen, Bestellungen lesen, Bestellungen schreiben – betreiben Ihren eigenen Shop oder Ihre eigene App auf derselben Bestell-Engine, wobei Preise immer serverseitig ermittelt werden.
Eingehende Webhooks, abgesichert
Jeder Webhook-Auslöser eines Flows hat seine eigene URL und sein eigenes Secret, HMAC-Prüfung über den Rohkörper und Replay-Schutz. Ein Payload darf eine Person benennen; das Innenleben des Flows steuern darf er nie.
Ausgehend über Flows
Der REST-Schritt ruft Ihre Systeme genau in den Momenten auf, die Sie auf der Arbeitsfläche zeichnen – Bestellung aufgegeben, Einwilligung erteilt, Termin gebucht.
Die Technik dahinter
Klar benannte Haltungen im API-Entwurf
Preise kommen nie vom Client
Eine Bestellanfrage sagt was und wie viele – Name und Preis werden in diesem Moment serverseitig aus dem Katalog gelesen und als Momentaufnahme auf die Position geschrieben. Eine manipulierte Anfrage kann sich keinen Rabatt ausdenken.
Erst die Fähigkeiten, dann der Aufruf
Jede Integrationsfläche veröffentlicht einen Fähigkeitsvertrag – kann sie über die Telefonnummer zuordnen, Gastbestellungen auflisten, Bestellungen anlegen? – und ein Aufruf über ein erklärtes „Nein“ hinaus wirft sofort einen Fehler, statt irgendwo in der Tiefe zu scheitern.
Fehler, die etwas bedeuten
Die Transportschicht unterscheidet „nicht berechtigt“ von „Dienst nicht verfügbar“ – aus „Der Shop ist nicht erreichbar“ wird also nie „Dieser Kunde hat nie etwas gekauft“. Benannte Fehler sind der Unterschied zwischen einer API und einem Ratespiel.
Webhooks, die keinen Replay zulassen
Jedes eingehende Event beansprucht vor der Verarbeitung einen eindeutigen Schlüssel in einem Idempotenz-Ledger – eine wiederholte oder erneut eingespielte Zustellung stirbt in der Datenbankschicht und nicht in Ihrer Automatisierung.
Keys gehasht, Secrets mit Scope
API-Keys liegen als Hashes; an der Tür lassen sich nur Hash und Scopes auflösen – eine abgeflossene Datenbankzeile nennt keinen Workspace und öffnet nichts jenseits ihrer Scopes.
Entwürfe und Bestätigungen sind ausdrücklich
Das Anlegen einer Bestellung nimmt einen ausdrücklichen Bestätigungsparameter entgegen – die öffentliche API steht standardmäßig auf bestätigt, Abläufe im Panel können Entwürfe vorbereiten –, sodass „Ist das echt?“ ein Feld ist und keine Konvention.
Einrichtung
So entsteht die Verbindung
Einen Key ausstellen
Legen Sie im Panel einen Commerce-API-Key mit Scopes an; zurückziehen lässt er sich genauso leicht.
Einen Webhook verdrahten
Legen Sie einen Flow mit Webhook-Auslöser an; signieren Sie Anfragen mit dessen Secret.
Nach außen zurückrufen
Setzen Sie REST-Schritte dorthin, wo Ihre Systeme davon erfahren müssen.
Gemeinsam stärker
Womit es zusammenspielt
Flows
Webhook-Auslöser starten Flows; REST-Schritte melden sich bei Ihren Systemen genau in den Momenten zurück, die Sie zeichnen – eingehende und ausgehende Automatisierung teilen sich eine Arbeitsfläche.
Commerce
Die Katalog- und Bestell-Engine hinter der API ist dieselbe, die auch der Chat-Shop und die KI nutzen – eine Bestellwahrheit, vier Türen.
Ihr eigener Shop
Teams betreiben heute Headless-Shops auf der Commerce-API – der Weg, den die Shopify-Seite ehrlich empfiehlt, solange der native Konnektor noch gebaut wird.
Sicherheit & Garantien
Die langweiligen Garantien
HMAC über den Rohkörper
Die Webhook-Prüfung signiert den rohen Anfragekörper mit einem Secret je Auslöser und vergleicht in konstanter Zeit – geparst wird erst nach dem Beweis.
Payloads sind Daten, nie Befehle
Ein Webhook-Payload darf sich auf eine Person beziehen; das Innenleben eines Flows steuern, Prompts umschreiben oder Werkzeuge aufrufen darf er nie. Die Grenze zwischen Daten und Anweisungen ist in der Architektur gezogen, nicht im Verhalten.
Rate-Limits an jeder Tür
Öffentliche Endpunkte laufen über die Standarddrosselung, und Leselimits werden serverseitig gedeckelt – ein schlecht benommener Client bremst sich selbst aus, nicht die Plattform.
Das ehrliche Kleingedruckte
Grenzen, klar benannt
Noch kein Ereignisstrom
Einen allgemeinen Webhook-Feed, der alles abonniert, gibt es nicht – ausgehende Events laufen heute über Flow-Schritte. Das steht hier, damit kein Vertriebsgespräch etwas anderes andeuten muss.
Begrenzte Lesevorgänge, mit Absicht
Ein Lesevorgang gibt bis zu 100 Zeilen zurück, mit Cursor – die API ist für den operativen Anschluss gebaut, nicht für den Massenexport. Wer Massen braucht, spricht mit uns, statt eine Lücke zu suchen.
Ehrlich angebunden schlägt lautstark beworben.
Jede Integration hier ist danach beschrieben, was sie wirklich tut – Richtung, Datenhoheit und Grenzen inklusive.