Ein Geschäftsführer einer zehnköpfigen E-Commerce GmbH bemerkt, dass keine Shopify-Bestellungen mehr in Weclapp ankommen. Der Support antwortet nicht. Die Buchhalterin wartet auf Rechnungen. Der Lagerbestand in Shopify zeigt noch 50 Einheiten, Weclapp kennt nur noch 12. Über den Tag verteilt gehen fünf Bestellungen verloren, bis jemand bemerkt, dass der Connector nicht mehr läuft.
Das ist nicht ein isolierter Fall. Nach dem Weclapp-Update berichten Nutzer von Shopify-, eBay- und Shopware-Fehlern, die Tage oder Wochen anhalten. Ein Nutzer berichtet von sieben Monaten fehlgeschlagener eBay-Importe. Ein anderer beklagt, dass nach einem Update die Versandinformationen nicht mehr zu Shopify übertragen werden. Der native Connector ist zu fragil für den Betrieb.
Für mittlere E-Commerce-Unternehmen im deutschsprachigen Raum ist das ein echtes Problem, weil die Zeit bis zur Problemlösung direkt Umsatz kostet.
Das echte Problem hinter dem Connector-Ausfall
Weclapp stellt native Connectoren für eBay, Shopify, Shopware und Magento bereit. Diese Connectoren arbeiten durch Abfragen des REST API in festen Abständen — sogenanntes Polling. Wenn Weclapp ein größeres Update einfährt, müssen diese Connectoren oft angepasst werden, weil sich interne Datenstrukturen ändern. Das klingt trivial, ist aber der Punkt, an dem regelmäßig etwas schiefgeht.
Der native Connector wird gebremst durch ein zentrales Design-Problem: Er ist eng an eine bestimmte Version des Weclapp API gekoppelt. Wenn das API sich ändert, funktioniert der Connector bis zur Anpassung nicht mehr. Es gibt keinen Puffer, keine Retry-Logik, keine Fehlerbehandlung, die auf menschliche Intervention wartet. Entweder läuft er, oder es geht nichts mehr.
Hinzu kommt ein zweites Problem: Der API-Error selbst ist kryptisch. Ein fehlgeschlagener eBay-Import gibt nur eine generische Exception zurück. Die echte Fehlermeldung ist nur über einen direkten REST-Call sichtbar, nicht über die Benutzeroberfläche. Das bedeutet: Der Connector schlägt fehl, der Support sieht keinen sauberen Fehler, und der Geschäftsführer sitzt dazwischen.
Das ist kein Designfehler von Weclapp allein — es ist ein strukturelles Versprechen-halte-Problem. Der native Connector verspricht, dass Ihre Marktplätze und Ihr ERP synchronisiert bleiben. Wenn er bricht, ist die Vertrauensgrundlage zerstört.
Die Lösung in der Praxis: Middleware mit Intelligenz
Eine Middleware-Schicht zwischen Ihren Marktplätzen und Weclapp löst dieses Problem vollständig. Sie funktioniert so:
Das System empfängt Bestellungen direkt von eBay, Shopify und anderen Plattformen. Es speichert sie zunächst lokal in einer Warteschlange (Dead-Letter Queue). Von dort aus versucht es, jede Bestellung ins Weclapp API zu schreiben. Wenn das fehlschlägt — weil der API gerade offline ist, weil ein Update läuft, oder weil eine Datenstruktur unerwartete Werte enthält — probiert das System es erneut. Mit exponentiellem Backoff, das heißt: erst nach 10 Sekunden, dann nach 1 Minute, dann nach 5 Minuten, dann nach einer Stunde.
Ein fehlgeschlagener Bestellimport blockiert nicht mehr den gesamten nächsten Durchlauf. Die Middleware merkt sich, dass diese Bestellung fehlgeschlagen ist, und kümmert sich um sie, bis sie durch ist.
Parallel dazu protokolliert die Middleware jeden Fehler: Ist es ein Authentifizierungsfehler? Ein Validierungsfehler? Ein Netzwerk-Timeout? Ein unerwartetes Feld im Bestell-Payload? Diese Details fließen in ein einfaches Dashboard, auf dem Sie Fehler nach Typ sortieren und filtern können. Sie sehen sofort, ob gerade 50 eBay-Bestellungen wegen desselben Fehlers steckenbleiben, oder ob es sich um einzelne Anomalien handelt.
Das System macht auch das, was ein guter Mensch tun würde: Es kennt die häufigsten Fehler und kann auf bekannte Probleme automatisch reagieren. Ein fehlgeschlagener Import wegen eines ungültigen Steuer-Codes? Das System kann Fallback-Werte verwenden oder die Bestellung in ein Triage-Feld legen, in dem ein Mensch sie manuell korrigiert, bevor sie ins System geht.
Außerdem bietet ein solches System einen Häkchen-basierten Wiederherstellungs-Workflow. Ein Update ist schief gelaufen? Ein Marktplatz war drei Stunden offline? Sie klicken nicht zehn Mal auf einen Reset-Button in Weclapp, sondern Sie wählen einen Zeitstempel, und das System importiert alle Bestellungen ab diesem Punkt neu.
Was dieses System konkret ändert
Nach vier Wochen Laufzeit zeigt sich der praktische Unterschied deutlich. Mit der nativ in Weclapp integrierten Connector-Lösung haben Sie Ausfallzeiten von durchschnittlich 12–36 Stunden nach einem Update. Mit einer Middleware passieren Ausfälle nur, wenn der Weclapp-Server selbst nicht erreichbar ist — nicht, wenn der Connector selbst veraltet ist.
Das heißt konkret: Bestellungen landen immer noch in Ihrer Warteschlange an. Sie werden aufgesammelt. Sobald Weclapp wieder ansprechbar ist oder ein Update komplett ist, fließen auch die ausstehenden Bestellungen nach. Ein E-Commerce-Manager sieht auf dem Dashboard in Echtzeit, wie viele Bestellungen gerade in der Warteschlange liegen und warum. Er kann manuelle Schritte einleiten, falls nötig. Aber er muss nicht mehr jede Stunde anrufen und fragen, ob der Support das Problem endlich gesehen hat.
Ein zweiter Effekt ist weniger offensichtlich, aber erheblich: Sie brauchen weniger Eskalationen. Eine Middleware mit guter Fehlerklassifizierung reduziert die Anzahl echts komplexer Probleme, die Sie an den Weclapp-Support bringen müssen. Die meisten Fehler werden entweder automatisch gelöst oder tauchen im Fehler-Dashboard auf, sodass Sie sie mit Kontext beschreiben können statt mit vagen Symptomen.
Ein dritter Effekt: Sie können schneller auf Probleme reagieren. Wenn Shopware eine neue API-Version released und der Weclapp-Connector wird langsam (weil Weclapp noch nicht angepasst wurde), Sie aber sehen das sofort in Ihrem Fehler-Dashboard, können Sie entscheiden: Warten wir, bis Weclapp angepasst hat, oder bauen wir einen lokalen Workaround? Bei vier Wochen Wartezeit in der Vergangenheit war das keine echte Wahl.
Implementierung und Betrieb
Ein solches System muss nicht von Grund auf neu gebaut werden. Es gibt etablierte Plattformen, die genau diesen Use-Case abdecken: Synesty Studio, Channable, oder auch n8n mit custom-gebauten Fehlerbehandlungs-Workflows. Die Auswahl hängt von Ihren Anforderungen ab.
Der Betrieb ist dann deutlich leichter. Statt täglich zu warten und zu hoffen, dass der Connector läuft, sehen Sie ein Dashboard. Sie wissen, wie viele Bestellungen in Ihrer Warteschlange sitzen, welche Fehlertypen es gibt, und ob ein Mensch eingreifen muss oder ob das System selbst wieder heilt.
Das ist kein Consulting-Projekt mit Endpunkt. Das ist eine technische Infrastruktur, die Sie am laufen halten, wie Sie auch Ihren Internet-Router oder Ihre Telefonanlage am Laufen halten.
Woran Sie merken, dass Sie dieses System brauchen
Sie brauchen eine Middleware, wenn eines dieser Szenarien regelmäßig vorkommt: Nach einem Weclapp-Update funktioniert der Shopify-Connector für sechs Stunden nicht. Sie müssen jeden Morgen überprüfen, ob die eBay-Importe funktionieren. Ein Connector-Fehler bricht den gesamten nächsten Import-Zyklus. Sie haben schon einmal Bestellungen manuell nacherfasst, weil ein Connector ausgefallen ist. Der Support kann Ihnen beim Connector-Problem nicht schnell genug helfen.
Sie brauchen keine Middleware, wenn Sie nur drei bis fünf Bestellungen pro Tag haben und alles noch manuell nachverfolgbar ist. Sie brauchen auch keine, wenn Sie keine Shopify oder eBay haben und nur Warehouse-Management laufen.
Aber für jedes E-Commerce-Unternehmen, das auf mehrere Marktplätze setzt und Weclapp als zentrales System nutzt, ist eine Middleware nicht optional. Sie ist der Punkt, an dem ERP nicht mehr "bricht, wenn das Update schief geht", sondern "läuft durch alles hindurch".