API und Webhook: Wie Shop, Warenwirtschaft und Tools miteinander sprechen

Eine API ist eine Schnittstelle, über die ein Programm Daten bei einem anderen abholt — Sie fragen, das andere System antwortet (Pull). Ein Webhook dreht die Richtung um: Das andere System meldet sich von selbst, sobald etwas passiert (Push). Im Handel brauchen Sie beides — und dazu Signaturprüfung, Wiederholungen und einen Abgleichlauf.

Stand: 6. September 2026. Alle Angaben zu JTL, Shopify und n8n stammen aus der jeweiligen Hersteller-Dokumentation und wurden an diesem Tag einzeln nachgelesen. Schnittstellen ändern sich mit jeder Version. Prüfen Sie vor der Umsetzung die Dokumentation zu genau der Version, die Sie einsetzen — die Belege verlinken wir am Ende.

1. Der Weg einer Bestellung: vier Übergaben, zwei Richtungen

Erklärungen zu Schnittstellen beginnen fast immer mit dem Bild vom Kellner, der eine Bestellung in die Küche trägt. Das Bild ist hübsch und hilft im Betrieb nicht weiter. Nützlicher ist ein echter Vorgang: eine Bestellung, die montagmorgens im Shop eingeht und bis Dienstag beim Kunden liegt.

Auf diesem Weg wechselt sie viermal das System. Jede dieser Übergaben folgt einem von zwei Mustern, und jede bricht auf eine eigene Weise. Die rechte Spalte beschreibt keinen theoretischen Fall — es sind die vier Störungen, die uns in Kundenprojekten am häufigsten begegnen:

Zwei Beobachtungen fallen sofort auf. Erstens taucht in einem einzigen Vorgang beides auf: Der Shop fragt die Warenwirtschaft nach Beständen, aber der Zahlungsdienst meldet sich von selbst. Wer nur eines von beiden kennt, baut die halbe Kette. Zweitens hat keine der vier Störungen etwas mit dem Verständnis von Schnittstellen zu tun. Sie entstehen alle im Betrieb — bei Wiederholungen, Kontingenten, Reihenfolgen und Schutzregeln. Genau darum geht es in diesem Beitrag.

2. API und Webhook: derselbe Zweck, zwei Richtungen

API steht für Application Programming Interface, auf Deutsch Programmierschnittstelle. Sie ist ein festgelegter Weg, auf dem ein Programm Daten eines anderen Programms lesen oder ändern darf: welche Adressen es gibt, welche Felder erlaubt sind, wie die Antwort aussieht. Der entscheidende Punkt: Sie müssen fragen. Solange niemand fragt, passiert nichts.

Ein Webhook kehrt die Richtung um. Sie hinterlegen bei einem Dienst eine Adresse Ihres eigenen Systems, und der Dienst ruft diese Adresse auf, sobald ein Ereignis eintritt. Deshalb heißt er auch „umgekehrte API". Sie fragen nicht mehr alle fünf Minuten nach neuen Zahlungen — Sie werden benachrichtigt.

Der Satz, der fast überall falsch steht

In nahezu jeder deutschsprachigen Erklärung — und auch in Googles automatisch erzeugter Suchantwort — stehen Webhooks für „Echtzeit" und APIs für „verzögert". Als Faustregel stimmt das. Als Betriebszusage ist es falsch, und die Hersteller sagen das selbst.

Shopify schreibt in der eigenen Dokumentation, dass die Reihenfolge innerhalb eines Themas nicht garantiert wird: Eine Meldung über eine Produktänderung kann vor der Meldung über die Anlage desselben Produkts eintreffen. Empfohlen wird deshalb, sich am mitgelieferten Zeitstempel zu orientieren statt an der Eingangsreihenfolge. Noch deutlicher wird der Abschnitt zum Abgleich: Eine App solle sich nicht darauf verlassen, Daten über Webhooks zu erhalten, weil die Zustellung nicht immer gewährleistet sei — für die Redundanz sei ein regelmäßiger Abgleichlauf vorgesehen, der die Daten aktiv nachholt (Quelle: Shopify, About webhooks, geprüft am 6. September 2026).

Daraus folgt die wichtigste Regel dieses Beitrags: Ein Webhook ersetzt den Abgleich nicht, er beschleunigt ihn. Wer Push einführt und Pull abschaltet, tauscht ein langsames System gegen ein lückenhaftes.

Beides in einer Plattform: das JTL-Beispiel

Dass Pull und Push kein Entweder-oder sind, zeigt JTL innerhalb der eigenen Entwicklerplattform besonders gut. Für Änderungen im ERP — Artikel, Kunden, Aufträge, Rechnungen, Bestände — beschreibt JTL signierte Webhooks: Das ERP schickt eine Meldung an die Adresse, die eine App in ihrer Beschreibungsdatei hinterlegt hat. Für Händleraktionen im Marktplatz-Bereich gilt das Gegenteil: Dort holt Ihre Anwendung die Ereignisse selbst ab, per Abruf der Ereignisliste, und bestätigt sie anschließend durch Löschen. Empfohlen wird ein Abstand von rund 60 Sekunden.

Der zweite Unterschied ist noch aufschlussreicher: Beim Push liegt die Verantwortung für die Zustellung beim Absender, beim Pull bei Ihnen. JTL warnt für den Pull-Fall ausdrücklich, dass unbestätigte Ereignisse bis zu zehnmal erneut zugestellt und danach dauerhaft verworfen werden. Wer nicht bestätigt, verliert den Vorgang — still.

3. REST, JSON und die fünf Methoden

Fast alle modernen Schnittstellen sprechen REST über HTTP. Das klingt sperrig und ist im Kern simpel: Jeder Datensatz hat eine Adresse, und was Sie mit ihm tun wollen, sagen Sie über die Methode. Fünf davon decken den Alltag ab.

Die Daten selbst reisen als JSON — ein Textformat aus Feldnamen und Werten, das Menschen lesen und Maschinen zuverlässig auseinandernehmen können. Ein Auftrag besteht darin aus Feldern wie orderNumber, customer und einer Liste von Positionen. Mehr Zauberei steckt nicht dahinter.

Wichtiger als das Format ist die Antwort. Jede Anfrage bekommt einen Statuscode, und der entscheidet, wie Ihr System weiterarbeitet. Diese sechs Fälle sollten Sie kennen, weil sie unterschiedliche Reaktionen verlangen:

Eine Warnung aus der JTL-Dokumentation gehört an dieser Stelle dazu: Der Statuscode allein reicht nicht. Eine Antwort kann den Code 200 tragen und trotzdem eine Fehlerliste im Rumpf enthalten — das gilt insbesondere bei GraphQL, dem zweiten Abfrageweg der JTL-Cloud. Wer nur auf den Code schaut, verbucht Fehler als Erfolg.

Neben REST begegnen Ihnen noch zwei ältere Verwandte. SOAP tauscht XML-Nachrichten aus und lebt in Bank- und Logistikumgebungen weiter. Der genormte Belegaustausch zwischen Handelspartnern läuft dagegen über eigene Formate und eigene Wege — was ihn von einer Web-Schnittstelle unterscheidet und wann Handelsketten ihn verlangen, haben wir im Beitrag zur EDI-Schnittstelle aufgeschrieben.

4. Authentifizierung: Die eigentliche Frage ist, wer den Schlüssel hat

Eine Schnittstelle, die jeder aufrufen darf, ist eine offene Tür zu Ihren Kundendaten. Deshalb verlangt jede ernsthafte API eine Anmeldung. In der Praxis begegnen Ihnen drei Verfahren, und JTL zeigt in einer einzigen Dokumentationsseite alle drei nebeneinander.

Die mittlere Zeile ist die gefährlichste, und sie betrifft die meisten Bestandskunden. Ein statischer Schlüssel ohne Ablaufdatum ist bequem: einmal eintragen, nie wieder anfassen. Genau deshalb liegt er nach zwei Jahren in drei Skripten, einer Tabelle und einem Postfach — und niemand weiß mehr, wer ihn kennt. Bei kurzlebigen Token erledigt der Ablauf einen Teil der Aufräumarbeit von selbst.

Für die JTL-Wawi im eigenen Haus kommt ein Detail hinzu, das den statischen Schlüssel noch gewichtiger macht. Laut JTL-Entwicklerplattform setzt die Wawi die Scopes einer App erst ab Version 2.2.0 beim Aufruf durch; die neueste stabile Version war am 25. September 2026 die 2.1.1. Wie Registrierung, Scopes und Lizenz dort zusammenspielen, zeigt unser Beitrag zur JTL-Wawi API im Praxis-Check.

Vier Regeln haben sich bei uns bewährt, unabhängig vom Verfahren:

• Ein Schlüssel je Anwendung, nie ein Sammelschlüssel. Nur so lässt sich einer sperren, ohne alles lahmzulegen.
• Nur die Rechte vergeben, die gebraucht werden. Ein Versandmodul braucht keinen Schreibzugriff auf Preise.
• Schlüssel gehören in die Umgebungskonfiguration, nicht in den Quelltext und nicht in eine Tabelle im geteilten Ordner.
• Ein Wechsel muss geübt sein. Wenn niemand weiß, wie ein Schlüssel getauscht wird, wird er im Ernstfall nicht getauscht.

5. Rate Limits: Warum die Schnittstelle plötzlich 429 zurückgibt

Jeder Anbieter begrenzt, wie oft Sie fragen dürfen. Das ist kein Schikane-Mechanismus, sondern Schutz vor einer einzelnen Anwendung, die das System für alle anderen langsam macht. Überschreiten Sie die Grenze, antwortet die Schnittstelle mit dem Statuscode 429.

JTL liefert die Kontingentlage in jeder Antwort mit: X-RateLimit-Limit nennt die erlaubte Zahl im aktuellen Fenster, X-RateLimit-Interval-Length-Seconds die Länge des Fensters, X-RateLimit-Remaining den Rest. Die Dokumentation empfiehlt, diese Werte nach jeder Anfrage zu lesen und rechtzeitig langsamer zu werden, statt auf den Fehler zu warten.

Eine Einschränkung nennen wir offen: Für die Cloud-ERP-Schnittstelle veröffentlicht JTL keine festen Zahlen. Die Dokumentation verweist stattdessen auf die genannten Kopfzeilen, weil die Grenzen je Endpunkt und Umgebung abweichen. Wir geben deshalb keine Werte an, die man nicht nachschlagen kann. Für die Marktplatz-Schnittstelle sind die Grenzen dagegen veröffentlicht:

Der Sprung von 10 auf 1.500 Anfragen je Minute zwischen den Routen erklärt ein Missverständnis, das uns oft begegnet: „Die API ist zu langsam" heißt fast nie, dass die Schnittstelle langsam ist. Es heißt, dass die Anwendung an der teuersten Route drückt, statt die günstige zu nutzen.

Drei Dinge kommen aus derselben Dokumentation und gehören in jedes Lastenheft. Erstens: Nach einem 429 wird nicht sofort erneut gefragt, sondern mit wachsendem Abstand und einem kleinen Zufallsanteil — sonst laufen alle Wiederholungen im Gleichtakt und treffen die Schnittstelle erneut gemeinsam. JTL nennt drei Versuche als Obergrenze; wer danach noch scheitert, hat ein Muster-, kein Timing-Problem. Zweitens: Die Grenzen in der Testumgebung unterscheiden sich von der Produktion — bestandene Tests sind kein Kapazitätsnachweis. Drittens empfiehlt JTL selbst, Webhooks statt Abfragen zu nutzen, wo es geht. Das ist der eigentliche Grund, warum Push im Handel überhaupt wichtig ist: nicht die Geschwindigkeit, sondern das gesparte Kontingent.

6. Webhook-Sicherheit: Die Signatur ist der ganze Schutz

Ein Webhook-Endpunkt ist eine Adresse im offenen Internet. Jeder, der sie kennt oder errät, kann darauf eine Nachricht schicken, die aussieht wie eine Zahlungsbestätigung. JTL formuliert das in der eigenen Dokumentation so deutlich, dass wir es sinngemäß wiedergeben: Eine ungeprüfte Zustellung ist als nicht vertrauenswürdige Eingabe zu behandeln, und die Signatur ist das Einzige, was eine echte Meldung von einer gefälschten unterscheidet.

Das Verfahren dahinter heißt HMAC und ist schnell erklärt. Absender und Empfänger kennen dasselbe Geheimnis. Der Absender berechnet aus dem Nachrichtenrumpf — und meist zusätzlich aus einem Zeitstempel — einen Prüfwert und schickt ihn in einer Kopfzeile mit. Der Empfänger rechnet mit demselben Geheimnis nach. Stimmen die Werte nicht überein, wird die Nachricht verworfen. Wer das Geheimnis nicht kennt, kann keinen gültigen Prüfwert erzeugen.

Bei den beiden hier betrachteten Anbietern sieht das so aus: Shopify schickt einen mit dem Client Secret gebildeten Prüfwert im Kopf X-Shopify-Hmac-Sha256 und weist ausdrücklich darauf hin, dass er über den rohen Rumpf gebildet wird und der Vergleich zeitkonstant erfolgen soll. JTL nutzt Kopfzeilen mit dem Präfix svix — eine für die Zustellkennung, eine für den Zeitstempel, eine für die Signatur.

Wie wir das selbst betreiben

Ein Beispiel aus dem eigenen Haus, weil es alle Bausteine in einem einzigen kleinen Ablauf zeigt. Wenn Sie auf dieser Website ein Formular absenden, geht der Lead nicht nur per E-Mail heraus, sondern zusätzlich als Webhook an einen nicht öffentlich dokumentierten Endpunkt unseres internen CRM. Den genauen Pfad nennen wir hier bewusst nicht — warum, steht zwei Absätze weiter. Vier Entscheidungen stecken darin:

• Signiert wird über Zeitstempel und Rumpf gemeinsam, nicht nur über den Rumpf. So lässt sich eine mitgeschnittene Meldung nicht Wochen später erneut einspielen. Der Empfänger akzeptiert nur ein enges Zeitfenster von wenigen Minuten.
• Übertragen wird exakt der Text, der signiert wurde. Wird der Rumpf zwischen Signieren und Senden noch einmal umgewandelt, passt der Prüfwert nicht mehr — ein Fehler, der sich schwer finden lässt, weil beide Seiten „richtig" arbeiten.
• Der Aufruf blockiert die Kundenantwort nicht. Der Browser bekommt seine Bestätigung, die Verbindung wird geschlossen, und erst danach geht der Webhook heraus — mit knapper Zeitgrenze und abgefangenen Fehlern. Ein langsames CRM darf niemals die Danke-Seite aufhalten.
• Jeder Lead trägt einen Wiedererkennungsschlüssel, abgeleitet aus der E-Mail-Adresse oder ersatzweise aus der auf Ziffern reduzierten Telefonnummer. Kommt derselbe Vorgang ein zweites Mal an, entsteht kein zweiter Datensatz.

Der letzte Punkt ist kein Detail, sondern der Kern des nächsten Kapitels. Und ein Hinweis für die Umsetzung: Der Endpunktpfad selbst ist ebenfalls schützenswert. JTL empfiehlt, einen nicht erratbaren Pfad zu wählen und ihn wie ein Geheimnis zu behandeln. Das ersetzt die Signatur nicht, senkt aber die Zahl der Zufallstreffer erheblich.

7. Wenn der Schutz die eigene Maschine aussperrt

Es gibt eine Störung, die fast alle Beteiligten zunächst an der falschen Stelle suchen: Der Webhook wird korrekt gesendet, die Signatur stimmt, der Endpunkt läuft — und trotzdem kommt nichts an. Der Grund liegt eine Ebene davor.

Schutzdienste wie Cloudflare unterscheiden Menschen von Maschinen. Ein Zahlungs-Webhook ist eine Maschine: kein Browser, kein JavaScript, kein Mausklick. Ohne Ausnahmeregel wird er behandelt wie jeder andere Roboter. Im JTL-Forum ist genau dieser Fall dokumentiert: Der Super Bot Fight Mode blockierte die Zahlungsbestätigungen von Mollie, bis der Händler eine Ausnahme für den Kennbegriff „Mollie HTTP client/1.0" anlegte. In einem zweiten berichteten Fall fiel der Abgleich der Warenwirtschaft aus, bis deren Adresse freigegeben war.

In unseren Kundenprojekten scheitern Cloudflare-Setups fast nie am Schutz, sondern an dem, was fälschlich als Roboter gilt. Wichtig für die Planung ist ein Unterschied zwischen den Tarifstufen: Der einfache Bot-Filter im kostenlosen Tarif kennt keine Ausnahmeregeln, der erweiterte Filter ab der nächsten Stufe schon. Wer Zahlungs-Webhooks betreibt, braucht diese Möglichkeit. Wie der Schutz insgesamt funktioniert, haben wir im Beitrag zu Cloudflare für Shop-Betreiber beschrieben; die Einrichtung für JTL-Shop samt Ausnahmen für Abgleich und Webhooks zeigt unsere Seite zu Cloudflare als DDoS- und Bot-Schutz.

Daraus folgt eine Prüfregel für jedes Anbindungsprojekt: Bevor Sie im Anwendungscode suchen, klären Sie, ob die Anfrage überhaupt bis dorthin gekommen ist. Firewall, Schutzdienst und Webserver protokollieren das. Eine halbe Stunde in diesen Protokollen spart regelmäßig einen ganzen Tag Fehlersuche.

8. Fehler und Idempotenz: Der Vorgang, der zweimal ankommt

Webhooks werden nach dem Prinzip „mindestens einmal" zugestellt. Das ist keine Schlamperei, sondern eine bewusste Entscheidung: Lieber eine Meldung doppelt als eine verlorene Zahlung. Für Sie heißt das, dass Ihr Endpunkt jede Meldung mehrfach verkraften muss.

Die Zahlen dazu sind belegt. Shopify wiederholt eine misslungene Zustellung achtmal über vier Stunden und löscht das Abonnement nach acht Fehlschlägen in Folge, sofern es über die Verwaltungsschnittstelle eingerichtet wurde. Die JTL-Marktplatz-Warteschlange stellt bis zu zehnmal erneut zu und verwirft das Ereignis danach dauerhaft. Für die JTL-ERP-Webhooks nennt die Dokumentation nur, dass wiederholt wird — eine Zahl steht dort nicht, und wir erfinden keine.

Der Begriff für die Lösung heißt Idempotenz: Dieselbe Meldung zweimal verarbeitet führt zum gleichen Ergebnis wie einmal verarbeitet. Praktisch bedeutet das:

• Jede Zustellung hat eine Kennung. Shopify liefert eine je Zustellung und zusätzlich eine je auslösender Aktion; JTL wiederholt bei Wiederholungen dieselbe Zustellkennung. Merken Sie sich verarbeitete Kennungen und verwerfen Sie Wiedergänger.
• Prüfen Sie vor dem Schreiben, ob der Vorgang schon existiert — über die Auftragsnummer, die Zahlungskennung oder einen eigenen Schlüssel. Das fängt auch Fälle, in denen die Kennung wechselt.
• Antworten Sie schnell und arbeiten Sie danach. Shopify nennt fünf Sekunden als Richtwert und empfiehlt eine Warteschlange; JTL formuliert es so, dass ein Zeitüberschritt aus einer zugestellten Meldung eine wiederholte macht. Nehmen Sie die Meldung an, legen Sie sie in eine Warteschlange, bestätigen Sie — und verarbeiten Sie im Hintergrund.
• Verlassen Sie sich nicht auf die Reihenfolge. Nutzen Sie den mitgelieferten Zeitstempel und lassen Sie ältere Stände nicht neuere überschreiben.

Und dann der Punkt, den fast jedes Projekt zunächst auslässt: der Abgleichlauf. Ein Vorgang, der nachts oder stündlich prüft, ob alle Aufträge eines Zeitraums wirklich angekommen sind, und Fehlendes nachholt. Er ist der einzige Schutz gegen die Meldung, die verloren ging, während Ihr Server neu startete. Shopify empfiehlt ihn ausdrücklich, JTL kennt für den Pull-Fall das gleiche Muster.

Ein Detail zur Nutzlast lohnt die Erwähnung, weil es eine verbreitete Fehlannahme auflöst: JTL schickt im Webhook nicht den geänderten Datensatz, sondern nur dessen Schlüssel und ein paar Angaben zur Änderung. Den aktuellen Stand holen Sie danach selbst über die Abfrageschnittstelle. Das klingt umständlich, hat aber einen handfesten Vorteil — Sie bekommen immer den jetzigen Stand, auch wenn die Meldung eine Stunde in einer Warteschlange lag. Push und Pull arbeiten hier zusammen, nicht gegeneinander.

Für Auswertungen gilt ein anderes Muster: Ein nächtlicher Stapellauf holt die Daten aus Shop, Warenwirtschaft und Marktplatz, formt sie um und lädt sie in eine gemeinsame Tabelle. Die Idempotenz aus diesem Kapitel gilt dort genauso. Google warnt etwa, dass geplante BigQuery-Abfragen zur vollen Stunde mehrfach auslösen können. Wie Sie so eine Strecke wiederholbar bauen, erklärt unser Beitrag zum ETL-Prozess im Handel.

9. Was eine Anbindung kostet — ehrlich beantwortet

„Was kostet eine API-Schnittstelle?" gehört zu den meistgestellten Fragen bei Google, und fast niemand beantwortet sie. Wir tun das auch nicht mit einer Zahl — aber wir sagen, warum, und was den Preis wirklich bestimmt.

Der Grund ist einfach: Der Aufwand hängt fast nie an der Schnittstelle. Zwei Systeme technisch zu verbinden ist an einem Tag machbar. Was Zeit kostet, sind die Fälle dazwischen. Diese sechs treiben den Aufwand in unseren Projekten am stärksten:

• Uneinheitliche Stammdaten. Wenn derselbe Artikel im Shop eine andere Nummer trägt als in der Warenwirtschaft, ist die Zuordnung ein eigenes Teilprojekt.
• Varianten, Stücklisten und Sets. Ein Set aus drei Artikeln muss beim Verkauf drei Bestände verändern — und beim Storno wieder zurück.
• Teillieferungen und Retouren. Der Weg vorwärts ist meist geradlinig. Der Weg rückwärts hat die Ausnahmen.
• Mehrere Lager oder Verkaufskanäle. Jede zusätzliche Quelle bringt eine neue Konfliktregel mit.
• Steuer- und Preislogik. Netto- gegen Bruttopreise, Kundengruppen, abweichende Steuersätze im Ausland.
• Betrieb und Überwachung. Wer merkt, dass seit vier Stunden keine Bestellung mehr durchkam? Ohne Antwort darauf ist die Anbindung unfertig.

Deshalb beginnt bei uns jedes Anbindungsprojekt mit einer Bestandsaufnahme der Daten, nicht mit der Technik — und die Schätzung kommt danach. Wer vorher eine Pauschale nennt, ohne diese Fälle zu kennen, rät. Wie wir dabei vorgehen, beschreibt unsere Seite zur individuellen Datenintegration. Wenn Sie einen Shopify-Shop an JTL-Wawi anbinden möchten, finden Sie die Besonderheiten dieser Kombination im Beitrag zum Shopify-Connector für JTL-Wawi.

10. Wann n8n reicht — und wann es mehr braucht

Nicht jede Verbindung verlangt eigene Software. Werkzeuge wie n8n nehmen Webhooks entgegen, rufen Schnittstellen auf, wandeln Felder um und verzweigen nach Bedingungen — ohne dass jemand eine Anwendung schreibt. Für viele Aufgaben ist das die richtige Größe.

Der Webhook-Knoten bringt dafür einiges mit: getrennte Adressen für Test und Produktion, Anmeldung per Basisverfahren, per Kopfzeile oder per Token, eine Liste erlaubter Absenderadressen, das Ausblenden bekannter Roboter und die Möglichkeit, den unveränderten Rumpf entgegenzunehmen. Die Nutzlast ist auf 16 Megabyte begrenzt; wer selbst betreibt, kann diesen Wert anheben.

Eine Lücke sollten Sie kennen, bevor Sie planen: Unter den unterstützten Anmeldeverfahren des Webhook-Knotens steht keine Signaturprüfung. Wer eine HMAC-Signatur von Shopify oder JTL prüfen will, nimmt den unveränderten Rumpf entgegen und rechnet in einem eigenen kleinen Schritt nach. Das geht — es ist aber Handarbeit, keine Einstellung.

Aus unserer Erfahrung verschiebt sich die Grenze an diesen Stellen:

• Hohes Aufkommen. Ein paar Hundert Vorgänge am Tag sind kein Thema. Bei Zehntausenden zählt jede Sekunde Verarbeitungszeit.
• Mehrstufige Abgleiche mit Zustand. Sobald der Ablauf sich merken muss, was gestern passiert ist, wird ein Ablaufwerkzeug zur Notlösung.
• Harte Fachlogik. Preisstaffeln, Steuerregeln, Stücklistenauflösung gehören in getesteten Code, nicht in verzweigte Bedingungsknoten.
• Nachweispflichten. Wer belegen muss, welcher Vorgang wann mit welchem Ergebnis verarbeitet wurde, braucht eine eigene Protokollierung.

Ein bewährter Weg ist die Kombination: Der Ablauf entsteht zuerst in n8n, weil er dort in Tagen statt Wochen läuft und die Fachlogik dabei sichtbar wird. Was sich bewährt und wächst, wandert später in eigene Software. Wie ein erster Ablauf entsteht, zeigt unser n8n-Tutorial; wie sich die größeren Werkzeuge dieser Klasse unterscheiden, haben wir im Vergleich der Middleware-Lösungen gegenübergestellt.

Eine dritte Bauform ist inzwischen dazugekommen: Anbindungen, über die ein KI-Assistent selbst auf Warenwirtschaft und Shop zugreift. Die Grundlagen dieses Beitrags gelten dort unverändert — Anmeldung, Rechte, Kontingente, Protokoll. Was das Protokoll zusätzlich regelt und welche Rechte Sie besser nie freigeben, steht im Beitrag zum Model Context Protocol.

Ein Grenzfall aus dem ERP-Alltag gehört dazu: Die Automatisierung in JTL-Wawi läuft ausschließlich ereignisgesteuert, und die zugehörige Schnittstelle befand sich am 7. September 2026 laut Hersteller weiterhin in der Open Beta. Wer dort etwas in festen Abständen prüfen will, entscheidet zwischen Aufgabenplaner, externem Ablaufwerkzeug und Schnittstelle. Die Abwägung führen wir im Beitrag zu JTL-Workflows aus.

11. Einführung in sechs Schritten

So gehen wir vor, wenn zwei Systeme verbunden werden sollen. Die Reihenfolge ist bewusst gewählt: Die Schritte, an denen Projekte scheitern, kommen zuerst.

1. Den Vorgang aufschreiben, nicht die Technik. Welche Ereignisse gibt es, wer ist die führende Quelle je Feld, was passiert bei Widerspruch? Eine Seite Papier verhindert mehr Ärger als jedes Werkzeug.
2. Die Dokumentation der Gegenseite lesen — beide Teile. Nicht nur die Liste der Adressen, sondern auch die Abschnitte zu Kontingenten, Wiederholungen und Signaturen. Dort steht, was Ihr Betrieb später aushalten muss.
3. Je Feld entscheiden, ob Pull oder Push passt. Ereignisse, die sofort wirken sollen, kommen per Push. Bestände und Preise holen Sie ab. Beides zusammen ergibt eine belastbare Kette.
4. Den Endpunkt absichern, bevor er echte Daten sieht. HTTPS mit gültigem Zertifikat, nicht erratbarer Pfad, Signaturprüfung, enges Zeitfenster, Ablehnung ohne Aussage über den Grund.
5. Doppelte Meldungen und den Abgleichlauf einplanen. Beides gehört in die erste Fassung, nicht in eine spätere Ausbaustufe. Nachrüsten heißt fast immer, Datensätze von Hand zu bereinigen.
6. Überwachung einrichten, bevor Sie live gehen. Eine Meldung, wenn seit einer definierten Zeit kein Vorgang mehr durchkam, ist wertvoller als jede Statistik. Sie verwandelt einen stillen Ausfall in einen bemerkten.

Auffällig ist, wie wenig davon mit der Wahl der Schnittstelle zu tun hat. Die Technik ist der einfache Teil. Der Aufwand steckt in den Regeln, und die Regeln kennt nur, wer den Betrieb kennt.

12. Fazit: Zwei Muster, vier Betriebsfragen

Der Unterschied zwischen API und Webhook ist in einem Satz erzählt: Bei der API fragen Sie, beim Webhook werden Sie gefragt. Wer nur das wissen wollte, ist hier fertig. Wer eine Anbindung verantwortet, hat vier weitere Fragen zu beantworten — und die entscheiden über Erfolg oder Dauerärger.

Wer hat den Schlüssel, und was passiert, wenn er wechseln muss? Wie oft dürfen wir fragen, bevor die Gegenseite abwinkt? Woran erkennen wir, dass eine Meldung echt ist? Und was passiert, wenn dieselbe Meldung zweimal kommt oder gar nicht? Auf diese vier Fragen antwortet keine der Glossarseiten, die bei Google ganz oben stehen. Im Betrieb sind es genau die vier, die zählen.

Unsere Empfehlung nach vielen solcher Projekte: Bauen Sie den Abgleichlauf von Anfang an mit, auch wenn die Webhooks sauber laufen. Er kostet einen Tag und ist der Unterschied zwischen einem Ausfall, den Sie am selben Vormittag bemerken, und einer Lücke, die drei Wochen später in der Buchhaltung auffällt. Wenn Sie eine bestehende Verbindung prüfen lassen oder eine neue planen möchten, sehen wir uns Ihre Systemlandschaft und Ihre Datenlage gemeinsam an.

13. Häufige Fragen zu API-Schnittstellen und Webhooks

Was ist eine API-Schnittstelle?

Eine API ist ein festgelegter Weg, auf dem ein Programm Daten eines anderen Programms abruft oder verändert. Sie legt fest, welche Adressen es gibt, welche Felder erlaubt sind und wie die Antwort aussieht. Im Handel hängen Shop, Warenwirtschaft, Versanddienst und Buchhaltung über solche Wege zusammen. Ohne API bleibt nur der Dateiaustausch.

Was ist der Unterschied zwischen API und Webhook?

Die Richtung. Bei einer API fragen Sie an und bekommen eine Antwort; nichts passiert, solange Sie nicht fragen. Ein Webhook kehrt das um: Das fremde System ruft Ihre Adresse auf, sobald ein Ereignis eintritt. Webhooks sparen Abfragen, dafür betreiben Sie eine erreichbare Adresse und prüfen jede Meldung auf Echtheit.

Welche Methoden gibt es bei einer REST-API?

Fünf Methoden decken den Alltag ab: GET holt Daten, POST legt einen neuen Datensatz an, PUT ersetzt einen vorhandenen vollständig, PATCH ändert einzelne Felder, DELETE löscht. Die Antwort trägt immer einen Statuscode. 200 heißt erledigt, 401 fehlende Anmeldung, 429 zu viele Anfragen, 500 ein Fehler auf der Gegenseite.

Was kostet eine API-Schnittstelle?

Das lässt sich seriös nur nach einer Bestandsaufnahme sagen, weil der Aufwand fast nie an der Schnittstelle selbst hängt. Teuer werden Sonderfälle: abweichende Artikelnummern, Bestände über mehrere Lager, Teillieferungen, Storno und Retoure. Wer eine Pauschale nennt, ohne diese Fälle zu kennen, rät. Wir schätzen erst nach dem Datenabgleich.

Was ist eine API-Anbindung?

So nennt man das Projekt, in dem zwei Systeme über ihre Schnittstellen verbunden werden. Dazu gehören die Zuordnung der Felder, die Regeln bei Konflikten, die Anmeldung, das Verhalten bei Ausfällen und die Überwachung im Betrieb. Der reine Aufruf einer Adresse ist dabei der kleinste Teil der Arbeit.

Wie sichern Sie einen Webhook ab?

Über eine Signatur. Der Absender bildet aus Zeitstempel und Rumpf einen Prüfwert mit einem gemeinsamen Geheimnis und schickt ihn im Kopf mit. Ihr Endpunkt rechnet nach und verwirft alles, was nicht passt oder zu alt ist. Shopify nutzt dafür den Kopf X-Shopify-Hmac-Sha256, JTL die Kopfzeilen mit dem Präfix svix.

Was passiert, wenn ein Webhook nicht ankommt?

Der Absender wiederholt. Shopify versucht es nach einem Fehler achtmal über vier Stunden und löscht das Abonnement nach acht Fehlschlägen in Folge, sofern es über die Admin-API eingerichtet wurde. JTL wiederholt ebenfalls. Deshalb muss Ihr Endpunkt dieselbe Meldung mehrfach verkraften, ohne die Buchung zweimal auszulösen.

Reicht n8n für eine API-Anbindung?

Für überschaubare Abläufe ja: n8n nimmt Webhooks entgegen, ruft Schnittstellen auf und wandelt Felder um. Grenzen erreichen Sie bei hohem Aufkommen, langen Warteschlangen, mehrstufigen Abgleichen und dann, wenn Sie Signaturen prüfen müssen — dafür bringt der Knoten keine eigene Funktion mit. Ab dort lohnt eine eigene Anwendung.

Hat JTL-Wawi eine API?

JTL dokumentiert für sein ERP eine Schnittstelle auf der Entwicklerplattform, mit REST- und GraphQL-Zugang sowie Ereignissen per Webhook. Die Anmeldung unterscheidet sich je Betriebsart: Die Cloud nutzt OAuth mit kurzlebigem Token, die Installation im Haus einen dauerhaften Schlüssel. Die Seite zur Wawi-Anbindung war am 6. September 2026 noch ein Platzhalter.

14. Quellen & Hersteller-Dokumentation

Alle wurden am 6. September 2026 abgerufen und inhaltlich gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• JTL — Webhooks & Events — beschreibt die Ereignissysteme der Plattform: signierte ERP-Webhooks mit Zustellung nach dem Prinzip „mindestens einmal", die Warnung zur ungeprüften Zustellung, die Nutzlast mit dem Schlüssel der geänderten Entität sowie die Abfrage-Warteschlange der Marktplatz-Schnittstelle samt Bestätigung und zehn Zustellversuchen.
• JTL — Handling Webhooks — Anforderungen an den Endpunkt (HTTPS mit gültigem Zertifikat, schnelle Antwort, Erfolgscode), die Empfehlung eines nicht erratbaren Pfads, der Aufbau der Nachricht und die drei Zustell-Kopfzeilen mit Kennung, Zeitstempel und Signatur.
• JTL — Rate Limits — Statuscode 429, die drei Kopfzeilen zur Kontingentlage (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Interval-Length-Seconds), die veröffentlichten Grenzen der Marktplatz-Schnittstelle, der Hinweis auf abweichende Werte in der Testumgebung und die Empfehlung eines ruhigen Abfragetakts von etwa einer Anfrage je 60 Sekunden. Abgerufen am 07.09.2026.
• JTL — OAuth 2.0 Flow — Grundlage der Tabelle mit den drei Anmeldeverfahren samt Token-Lebensdauern und dem Hinweis, dass die Schnittstelle im eigenen Haus einen dauerhaften Schlüssel ohne OAuth verwendet.
• Shopify — About webhooks — Beleg dafür, dass die Reihenfolge nicht garantiert wird und dass sich eine Anwendung nicht allein auf Webhooks verlassen soll; empfiehlt einen regelmäßigen Abgleichlauf.
• Shopify — Verify webhook deliveries — Signaturprüfung über den unveränderten Rumpf, Entdopplung über die Zustellkennung, Richtwert von fünf Sekunden für die Antwort sowie die Angabe zu acht Wiederholungen über vier Stunden und zur Löschung des Abonnements danach.
• Shopify — Webhook delivery structure — die Übersicht aller mitgelieferten Kopfzeilen samt Zeitstempel und Versionsangabe.
• n8n — Webhook-Knoten — getrennte Adressen für Test und Produktion, die unterstützten Anmeldeverfahren (ohne Signaturprüfung), die Optionen für unveränderten Rumpf, Adressliste und Roboter-Filter sowie die Grenze der Nutzlast.
• JTL Developer Platform — Ausgangspunkt der JTL-Dokumentation. Die dortige Seite zur Wawi-Anbindung war am 6. September 2026 noch ein Platzhalter; deshalb stützen wir Wawi-bezogene Aussagen ausschließlich auf die oben verlinkten Seiten.