Weclapp Webhooks — was sie können, was sie nicht können, und wie du das Beste rausholst

Webhooks sind der schnellste Weg um auf Weclapp-Ereignisse zu reagieren. Aber wer sie zum ersten Mal einsetzt, stößt schnell auf eine Einschränkung die in der Dokumentation kaum erwähnt wird. Dieser Artikel erklärt Weclapp-Webhooks von Grund auf — ehrlich, vollständig und mit praktischen Lösungen.

Was Webhooks sind und warum sie nützlich sind

Ein Webhook ist eine automatische Benachrichtigung die ein System sendet wenn ein bestimmtes Ereignis eintritt. Anstatt dass dein Tool regelmäßig bei Weclapp nachfragt "Hat sich etwas geändert?" — was als Polling bezeichnet wird und ineffizient ist — schickt Weclapp aktiv eine Nachricht wenn etwas passiert.

Das macht Webhooks ideal für Echtzeit-Automatisierungen: neuer Auftrag angelegt, Kunde geändert, Rechnung erstellt. Dein Automatisierungs-Tool reagiert sofort — ohne Verzögerung, ohne unnötige API-Last.

Webhook in Weclapp einrichten

Verfügbare Entitäten

Weclapp unterstützt Webhooks für 28 Entitätstypen. Die wichtigsten für Automatisierungen:

Der Payload — und das Problem damit

Hier liegt die entscheidende Einschränkung die viele Nutzer erst im Praxiseinsatz entdecken. Was Weclapp bei jedem Event sendet:

Drei Felder. Das ist die bewusste Design-Entscheidung von Weclapp — leichtgewichtig, schnell, zuverlässig zugestellt. Für den technischen Betrieb macht das Sinn.

Für eine praktische Automatisierung ist es jedoch fast unbrauchbar. Du weißt dass ein Auftrag angelegt wurde — aber nicht von wem, über welchen Betrag, in welchem Status, mit welchen Positionen.

Das verschachtelte Nachlade-Problem

Die naheliegende Lösung: Rufe nach Empfang des Webhooks die Weclapp API ab und hole dir die vollständigen Daten. Klingt einfach — aber Weclapp-Objekte sind verschachtelt:

• Du holst den Auftrag → bekommst eine customerId, keine Kundendaten
• Du holst den Kunden → bekommst eine defaultShippingAddressId, keine Adresse
• Du holst die Adresse → jetzt hast du die Adresse
• Der Auftrag hat Ansprechpartner → auch die sind nur IDs
• Custom Fields haben eigene IDs die aufgelöst werden müssen

Ein vollständiger Datensatz bedeutet oft 4-6 verschachtelte API-Calls. Für jeden davon brauchst du Fehlerbehandlung, Rate-Limit-Logik und Retry-Mechanismen.

Retry-Verhalten und Fehlerbehandlung

Weclapp hat eine eingebaute Retry-Logik für den Fall dass dein Endpunkt nicht erreichbar ist:

• 1. Wiederholung nach 1 Minute
• 2. Wiederholung nach 5 Minuten
• 3. Wiederholung nach 30 Minuten
• 4. Wiederholung nach 5 Stunden
• 5. Wiederholung nach 1 Tag

Diese Retry-Logik schützt gegen kurzzeitige Ausfälle deines Endpunkts. Sie hilft aber nicht wenn das Problem beim Nachladen der Daten liegt — also wenn dein Endpunkt den Webhook empfängt, aber der anschließende API-Call an Weclapp fehlschlägt.

Webhook-Anreicherung als Lösung

Statt das Datenproblem in jedem Automatisierungs-Tool einzeln zu lösen, gibt es einen eleganteren Weg: Eine Middleware die die Anreicherung zentral übernimmt — bevor der Payload dein Tool erreicht.

Das ist der Kerngedanke hinter Synclapp. Weclapp sendet den schlanken Webhook an Synclapp. Synclapp löst alle verschachtelten Referenzen auf, baut den vollständigen Datensatz zusammen und leitet ihn an dein Automatisierungs-Tool weiter. Was Make, Zapier oder n8n empfangen sind vollständige, sofort nutzbare Daten — ohne zusätzliche API-Calls, ohne Fehlerbehandlung, ohne Wartungsaufwand.

Fragen? Schreib uns an hello@synclapp.com.