n8n 4 weclapp: Lieferadressen mit DHL prüfen

Eine falsche Lieferadresse fällt oft erst auf, wenn am Packtisch das Label nicht gedruckt wird oder das Paket zurückkommt. Dann ist der Auftrag bestätigt, die Lieferung angelegt und die Kundin wartet. Diese Seite zeigt, wie der Agent die Prüfung vor die Auftragsbestätigung zieht, welche Aufträge er prüft, was DHL dabei prüft und was nicht, und wie du ihn einrichtest.

Das Wichtigste in Kürze

• Prüfen vor dem Bestätigen. Der Agent nimmt nur Aufträge im Status „In Erfassung“ (ORDER_ENTRY_IN_PROGRESS), also bevor Lieferung und Label entstehen.
• DHL prüft, legt aber nichts an. Der Aufruf POST /orders?validate=true der DHL Parcel DE Shipping API prüft die Sendung wie beim Labeldruck; laut DHL entstehen dabei keine Sendung und kein Label.
• Ergebnis direkt am Auftrag. Jeder geprüfte Auftrag bekommt das Ja/Nein-Feld address check done; bei Warnung oder Fehler zusätzlich address needs review und einen Kommentar mit den Meldungen von DHL.
• Altbestand bleibt unberührt. Der Agent prüft nur Aufträge ab dem Stichtag startDate, höchstens 10 je Lauf, und startet nach dem Import im Probelauf, der in weclapp nichts ändert.
• Grenze: DHL sagt, ob ein Label möglich ist, nicht, ob die Empfängerin dort wohnt. Geprüft werden nur Lieferadressen in Deutschland.

Was bringt dir der Agent?

Der Agent bringt Fehler nach vorn: Eine Adresse, für die DHL kein Label drucken würde, fällt nicht am Packtisch auf, sondern Minuten nach dem Auftragseingang, solange der Auftrag noch in Erfassung ist. Wer den Auftrag bestätigt, sieht das Kennzeichen und den Kommentar und kann die Kundin fragen, bevor Ware gepickt ist. Das spart keine Arbeit, die heute jemand bewusst macht; es verhindert Nacharbeit, die heute unbemerkt entsteht.

Wie viel das für dich wert ist, hängt von deinen eigenen Zahlen ab. Setz sie in diese Rechnung ein:

Größe	Woher du sie bekommst
A: DHL-Aufträge mit Lieferadresse in Deutschland im Monat	weclapp, Auftragsliste nach Versandart
B: Anteil davon mit Adressproblem	erste Woche im Echtbetrieb: Aufträge mit address needs review geteilt durch alle mit address check done
C: Minuten Nacharbeit je Problemadresse am Packtisch oder nach einem Rückläufer	deine Schätzung oder Messung
D: Minuten je Problemadresse, wenn der Agent sie vor der Bestätigung meldet	deine Schätzung, meist eine Rückfrage und eine Korrektur
Ersparnis im Monat in Minuten	A × B × (C − D)

Einen ersten Eindruck gibt dir der Probelauf, ohne dass in weclapp etwas geändert wird: Er prüft die ältesten Aufträge in Erfassung, höchstens maxPerRun, und bei jedem Probelauf wieder dieselben. Für B zählt deshalb erst der Echtbetrieb. Rückläuferkosten bei DHL und verärgerte Kundschaft sind in der Rechnung nicht enthalten.

Fazit: Der Agent ersetzt keinen Arbeitsschritt, er verschiebt die Entdeckung falscher Adressen an den Punkt, an dem die Korrektur am wenigsten kostet.

Wie arbeitet der Agent?

Der Agent läuft in fünf Schritten, jeder als eigener Node in n8n:

1. Start und Einstellungen: alle 15 Minuten über „Every 15 minutes“ oder von Hand über „Manual start“. „Check settings“ bricht ab, solange in Constants ein Platzhalter, ein ungültiger Stichtag, eine falsche DHL-Adresse oder eine fehlende Mailadresse steht.
2. Aufträge holen: „Get orders“ liest Aufträge in Erfassung ab startDate in deinen Vertriebswegen ohne address check done, der älteste zuerst. „Select orders“ prüft jeden Auftrag danach noch einmal selbst.
3. Bei DHL anmelden: Der Agent holt ein Token über die DHL-Anmeldung und verwendet es weiter, bis es abläuft. Nach einer gescheiterten Anmeldung wartet er dhlPauseAfterFailureMinutes (Standard 60 Minuten), bevor er es erneut versucht; jede weitere gescheiterte Anmeldung verdoppelt die Pause, bis höchstens 24 Stunden.
4. Adressen prüfen: „Build DHL request“ baut aus allen Aufträgen des Laufs eine Anfrage, „DHL validate“ schickt sie mit validate=true an DHL, „Evaluate DHL answer“ ordnet jeder Sendung ihr Ergebnis zu.
5. Zurückschreiben und melden: Je Auftrag setzt „Mark order“ die Kennzeichen und „Add comment“ bei Problemen den Kommentar. „Summary“ zählt die Ergebnisse; gab es technische Fehler, geht eine Mail raus und der Lauf endet als fehlgeschlagen.

Der Agent in n8n: links die Auswahl der Aufträge, in der Mitte die DHL-Prüfung, rechts das Zurückschreiben nach weclapp und darunter der Fehlerweg.

Fazit: Eine Abfrage in weclapp, ein Aufruf bei DHL für alle Aufträge des Laufs, zwei kleine Schreibvorgänge je Auftrag.

Welche Aufträge prüft der Agent, welche nicht?

Der Agent prüft Aufträge, die in weclapp noch in Erfassung sind, ab dem Stichtag angelegt wurden (Auftragsdatum orderDate), aus einem der Vertriebswege in salesChannels stammen und noch kein address check done tragen.

• Stichtag: Setz startDate auf heute, sonst prüft und kommentiert der Agent auch alte Aufträge, die noch in Erfassung stehen. Im Test mit einem Stichtag weit in der Vergangenheit griff der Agent sofort auf Altaufträge zu und meldete, dass weitere warten. Solange der Platzhalter drinsteht, läuft er nicht.
• Menge je Lauf: höchstens 10 Aufträge (maxPerRun, erlaubt 1 bis 30, weil DHL höchstens 30 Sendungen je Anfrage annimmt). Liegen mehr bereit, kommen sie im nächsten Lauf dran.
• Doppelte Sicherheit: „Select orders“ prüft Status, Auftragsdatum, Vertriebsweg und Kennzeichen an jedem Datensatz noch einmal, bevor etwas geprüft oder geschrieben wird, und nimmt jeden Auftrag nur einmal.
• Einmal geprüft ist geprüft: address check done ist die Sperre am Auftrag. Ein Auftrag, an dem es gesetzt ist, wird nicht wieder ausgewählt; ändert ihr danach die Adresse, prüft der Agent sie nicht neu, solange ihr das Feld nicht zurücksetzt.
• Bewusst nicht: Bestätigte Aufträge, Aufträge vor dem Stichtag und andere Vertriebswege fasst der Agent nicht an. Aufträge mit Lieferadresse außerhalb Deutschlands markiert er als „nicht geprüft“ (Ergebnis skipped), ohne Kommentar.

Fazit: Der Agent sieht nur neue Aufträge in Erfassung, und jeden davon genau einmal.

Was prüft DHL, und was schreibt der Agent zurück?

DHL prüft die Sendung so, wie sie beim Labeldruck ankäme: ob Straße, Hausnummer, Postleitzahl und Ort zusammenpassen. Packstation und Postfiliale erkennt der Agent und schickt sie als solche mit Postnummer; DHL prüft dann die Angaben zur Station oder Filiale. Vorher fängt der Agent selbst ab, was DHL gar nicht erst sinnvoll prüfen kann.

Ergebnis	Wann	Was der Agent in weclapp setzt
ok	DHL hat nichts zu beanstanden	address check done
warning	DHL würde drucken, meldet aber etwas, z. B. „house number not found“ oder „city does not match the postcode“; oder die Straße hat keine erkennbare Hausnummer	address check done, address needs review, Kommentar
fail	DHL lehnt ab, z. B. „Please enter a house number“; oder Straße, Postleitzahl, Ort oder Lieferland fehlen; oder ein Feld ist länger, als DHL annimmt (Straße 50, Adresszusatz 60, Ort 40 Zeichen); oder eine Packstation-Angabe ist nicht eindeutig lesbar	address check done, address needs review, Kommentar
skipped	Lieferadresse außerhalb Deutschlands	address check done
error	technisches Problem: Anmeldung, Zeitüberschreitung, Serverfehler bei DHL	nichts, der nächste Lauf prüft erneut

Der Kommentar am Auftrag nennt das Ergebnis, die geprüfte Lieferadresse und jede Meldung von DHL im Wortlaut, zum Beispiel „DHL consignee: Please enter a house number.“ address needs review setzt der Agent nur, er setzt es nicht zurück: Das Feld nimmt dein Team heraus, wenn die Adresse korrigiert oder bestätigt ist.

Was DHL nicht prüft: ob die Empfängerin unter der Adresse wohnt, ob der Name zur Postnummer gehört und nicht jede falsche Hausnummer in einer echten Straße. Einen Korrekturvorschlag macht der Agent nicht.

Fazit: DHL beantwortet die Frage „Würde das Label gedruckt?“; der Agent legt die Antwort an den Auftrag, wo dein Team sie sieht.

Was passiert bei einem Fehler?

Ein technischer Fehler schreibt nichts: Kann der Agent DHL nicht erreichen oder scheitert die Anmeldung, bekommt jeder Auftrag des Laufs das Ergebnis error, kein Kennzeichen und keinen Kommentar. Im nächsten Lauf ist er wieder dabei.

• Anmeldepause: Nach einer gescheiterten DHL-Anmeldung oder einer Antwort 401 meldet sich der Agent dhlPauseAfterFailureMinutes lang nicht neu an; jede weitere gescheiterte Anmeldung verdoppelt die Pause, bis höchstens 24 Stunden. Mit falschen Zugangsdaten versucht er es so am ersten Tag nur wenige Male und danach einmal am Tag. Bis dahin meldet er jeden Auftrag mit dem Hinweis auf die Pause.
• Keine Wiederholung beim Schreiben: „Mark order“ und „Add comment“ wiederholt der Agent nicht automatisch, damit kein Kommentar doppelt entsteht. Scheitert nur der Kommentar, trägt der Auftrag schon address needs review, und die Fehlermail sagt, dass der Kommentar fehlt.
• Fehlermail: oben, was zu tun ist und was danach passiert, darunter eine Tabelle mit Auftragsnummer und Grund, Zeitpunkt und Link zur Ausführung in n8n. Betreff zum Beispiel Address check: 1 order could not be checked or updated, eine Zeile zum Beispiel DHL login: HTTP 401: API Authentication failed: Invalid client identifier.
• Gedrosselt: Derselbe Grund zum selben Auftrag kommt höchstens einmal in errorMailRepeatHours (Standard 24 Stunden). Bei falschen DHL-Zugangsdaten kommt für dieselben Aufträge eine Mail zur gescheiterten Anmeldung und eine zur Pause; neu eingegangene Aufträge stehen in der nächsten Mail. Die Drosselung liegt in den statischen Daten des Workflows, die n8n nur bei aktiven Läufen speichert.
• Sichtbar: Ein Lauf mit Fehlern endet über „Stop with errors“ als fehlgeschlagen und steht so in der Ausführungsliste von n8n. Scheitert schon das Lesen der Aufträge in weclapp nach drei Versuchen, endet der Lauf ohne Mail als fehlgeschlagen; diesen Fall meldet dir ein Error-Workflow in n8n, falls du einen eingerichtet hast.

Starte den Agent nicht von Hand, während der Zeitplan läuft: Zwei gleichzeitige Läufe können denselben Auftrag zweimal kommentieren.

Fazit: Ein technischer Fehler kostet einen Lauf, keinen Auftrag, und bei DHL- und Schreibfehlern erfährst du davon per Mail.

Wie richtest du den Agent ein?

Du brauchst:

• n8n, selbst gehostet oder in der Cloud;
• einen weclapp-API-Token eines Benutzers, der Aufträge bearbeiten und kommentieren darf;
• zwei eigene Ja/Nein-Felder für Aufträge in weclapp: address check done und address needs review;
• eine App im DHL-Entwicklerportal mit Freigabe für die Parcel DE Shipping API (API-Key und Secret), einen Benutzer des DHL-Geschäftskundenportals und deine 14-stellige Abrechnungsnummer für DHL Paket (V01PAK);
• für die Fassung mit Community-Node das Paket @wals-pro/n8n-nodes-weclapp;
• ein SMTP-Konto für die Fehlermail.

So richtest du es ein:

1. Agent importieren: in n8n „Import from File“ und die JSON-Datei der passenden Fassung wählen.
2. weclapp-Zugang: mit Community-Node ein Credential Weclapp API an den drei weclapp-Nodes; in der HTTP-Fassung weclappBaseUrl in Constants und ein Credential Header Auth mit dem Namen AuthenticationToken und deinem Token als Wert.
3. DHL-Zugang: ein Credential Custom Auth an „DHL login“ mit Benutzer, Passwort, API-Key und Secret; die Vorlage steht in der Notiz im Workflow und in der Anleitung.
4. Constants füllen: salesChannels, startDate (heute), die IDs der beiden Ja/Nein-Felder, dhlBillingNumber, deine Absenderadresse, emailFrom, emailRecipientList und n8nBaseUrl. SMTP-Credential an „Send error email“ hängen.
5. Probelauf: dryRun steht nach dem Import auf true. „Manual start“ ausführen und in „Summary“ lesen, was DHL zu jedem Auftrag sagt. DHL wird gefragt, in weclapp ändert sich nichts.
6. dryRun auf false, einmal von Hand laufen lassen, die Kennzeichen und Kommentare in weclapp ansehen, dann aktivieren.

Willst du, dass nur geprüfte Adressen bestätigt werden, lass deine Bestätigungsregel nur Aufträge mit address check done = ja und address needs review = nein durch. Nur auf address needs review auszuschließen reicht nicht: Ein Auftrag, den der Agent noch nicht geprüft hat oder bei dem DHL nicht erreichbar war, trägt keines der beiden Felder. Der Agent selbst hält keinen Auftrag an. Jeden Schritt, jede Konstante und jede Fehlermeldung erklärt die Anleitung im Download.

Fazit: Drei Zugänge, zwei Ja/Nein-Felder, ein Stichtag, ein Probelauf, dann scharf.

Steckbrief

Was	Lieferadressen neuer weclapp-Aufträge vor der Bestätigung bei DHL prüfen und das Ergebnis am Auftrag ablegen
Auslöser	alle 15 Minuten, zusätzlich manuell
Auswahl	Status ORDER_ENTRY_IN_PROGRESS, Auftragsdatum ab startDate, Vertriebswege aus salesChannels, ohne address check done, älteste zuerst
Schutz	läuft erst mit gesetztem Stichtag, Feld-IDs, DHL-Daten und Mailadressen; startet im Probelauf (dryRun); prüft jeden Auftrag vor dem Schreiben noch einmal; Anmeldepause bei falschen DHL-Zugangsdaten
Menge je Lauf	höchstens 10 Aufträge (maxPerRun, bis 30), eine DHL-Anfrage je Lauf
Prüfung	DHL Parcel DE Shipping API v2, POST /orders?validate=true, Produkt DHL Paket V01PAK, Packstation und Postfiliale eingeschlossen
Ergebnis	Ja/Nein-Felder address check done und address needs review, Kommentar am Auftrag bei Warnung oder Fehler
Fehler	nichts geschrieben, nächster Lauf prüft erneut, gedrosselte Fehlermail, Lauf endet als fehlgeschlagen
Grenzen	nur Lieferadressen in Deutschland, kein Korrekturvorschlag, hält keinen Auftrag an, prüft nicht die Zustellbarkeit an die Person
Fassungen	mit Community-Node @wals-pro/n8n-nodes-weclapp und mit HTTP-Request-Nodes (weclapp REST API v2); DHL in beiden über HTTP-Request-Nodes
Version	1.0 vom 07.11.2026

Was ist im Download?

• Anleitung als PDF: Einrichtung, alle Konstanten, DHL-Zugang, Probelauf, Aktivieren und jede Fehlermeldung mit Lösung.
• Agent mit Community-Node: check-addresses-dhl.weclapp-node.json für n8n mit installiertem @wals-pro/n8n-nodes-weclapp.
• Agent als HTTP-Fassung: check-addresses-dhl.http.json für n8n ohne Community-Nodes, zum Beispiel n8n Cloud.

Der Agent kostet nichts: Du schließt die Bestellung zu 0 € ab und bekommst den Download-Link mit der Bestellbestätigung per Mail und auf der Bestellstatusseite.

Fazit: Beide Fassungen tun dasselbe – nimm die, die zu deiner n8n-Instanz passt.

Was passt dazu?

• Auftragsabwicklung auf Autopilot: Der kostenlose Agent bestätigt Aufträge, legt Lieferungen und Rechnungen an. Läuft die Adressprüfung davor, sieht dein Team Problemadressen, bevor der Autopilot weitermacht; dort lässt du nur Aufträge mit address check done = ja und address needs review = nein durch.
• Lieferscheine automatisch erstellen: der nächste Schritt nach der Bestätigung, sobald die Ware vollständig verfügbar ist.
• Retourenetiketten automatisch erstellen: legt Retourenlabels für DHL, DPD und andere Versanddienstleister an, wenn ein Auftrag sie braucht.
• Fulfillment 4 weclapp: die Packtisch-App für weclapp; dort druckst du die Versandlabels, deren Adressen der Agent vorher geprüft hat.
• Versand-Anbindungen für weclapp nach Anwendungsfall: welche Anbindung zu DHL, DPD, UPS und Co. für welchen Fall passt.

Fazit: Die Adressprüfung ist der erste Baustein vor Bestätigung, Lieferschein und Label.

Technik: Wie sehen die Aufrufe an weclapp und DHL aus?

Die HTTP-Fassung macht drei Aufrufe gegen die weclapp REST API v2 und zwei gegen DHL. Zum Nachvollziehen mit curl, Platzhalter in spitzen Klammern. Aufträge holen:

curl -G "https://<dein-mandant>.weclapp.com/webapp/api/v2/salesOrder" \
  -H "AuthenticationToken: <dein-token>" \
  --data-urlencode 'filter=(status = "ORDER_ENTRY_IN_PROGRESS") and (orderDate >= <Stichtag in Millisekunden>) and (salesChannel in ["NET1"]) and (customAttribute<ID address check done> = false)' \
  --data-urlencode "sort=orderDate" \
  --data-urlencode "properties=id,orderNumber,status,orderDate,salesChannel,customAttributes,deliveryAddress" \
  --data-urlencode "pageSize=11"

Bei DHL anmelden und prüfen:

curl -X POST "https://api-eu.dhl.com/parcel/de/account/auth/ropc/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "grant_type=password&username=<portal-benutzer>&password=<portal-passwort>&client_id=<api-key>&client_secret=<api-secret>"

curl -X POST "https://api-eu.dhl.com/parcel/de/shipping/v2/orders?validate=true" \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{"profile": "STANDARD_GRUPPENPROFIL", "shipments": [{"product": "V01PAK", "billingNumber": "<abrechnungsnummer>",
       "refNo": "<auftragsnummer>", "shipper": {"name1": "<firma>", "addressStreet": "<straße nr>", "postalCode": "<plz>", "city": "<ort>", "country": "DEU"},
       "consignee": {"name1": "<name>", "addressStreet": "<straße nr>", "postalCode": "<plz>", "city": "<ort>", "country": "DEU"},
       "details": {"weight": {"uom": "g", "value": 1000}}}]}'

DHL antwortet je Sendung in items mit sstatus und validationMessages; jede Meldung hat einen validationState (Error oder Warning). Eine Packstation geht als {"name": …, "lockerID": 123, "postNumber": …}, eine Postfiliale mit retailID. Dann je Auftrag die Kennzeichen und bei Problemen der Kommentar:

curl -X PUT "https://<dein-mandant>.weclapp.com/webapp/api/v2/salesOrder/id/<id>?ignoreMissingProperties=true" \
  -H "AuthenticationToken: <dein-token>" -H "Content-Type: application/json" \
  -d '{"customAttributes": [{"attributeDefinitionId": "<ID address check done>", "booleanValue": true},
                         {"attributeDefinitionId": "<ID address needs review>", "booleanValue": true}]}'

curl -X POST "https://<dein-mandant>.weclapp.com/webapp/api/v2/comment" \
  -H "AuthenticationToken: <dein-token>" -H "Content-Type: application/json" \
  -d '{"entityName": "salesOrder", "entityId": "<id>", "privateComment": false, "publicComment": false, "comment": "Address check (DHL): not shippable …"}'

Mit ignoreMissingProperties=true ändert weclapp nur die mitgeschickten eigenen Felder; alle anderen Felder des Auftrags bleiben, wie sie sind.

Fazit: Ein GET bei weclapp, ein Prüfaufruf bei DHL, ein PUT und höchstens ein Kommentar je Auftrag.

Quellen und Grenzen

• DHL Developer Portal: Parcel DE Shipping API (Post & Parcel Germany) v2, Version 2.1.13, Parameter validate: „no state changes are happening, no data is stored“, abgerufen am 06.11.2026.
• weclapp REST API v2: Endpunkte salesOrder und comment, Filter customAttribute<ID>, laut OpenAPI-Beschreibung des Mandanten, abgerufen am 06.11.2026.
• n8n-Dokumentation: getWorkflowStaticData, Speicherung nur bei aktiven Läufen, abgerufen am 06.11.2026.

Getestet haben wir den Agent am 06.11.2026 in einem weclapp-Testmandanten gegen die DHL-Sandbox, beide Fassungen: Probelauf, Schreiblauf, Sperre, Stichtag, falsche Zugangsdaten mit Fehlermail und Anmeldepause. Gegen die DHL-Produktionsumgebung lief der Agent noch nicht; die Sandbox bewertet nach eigenem Datenstand und meldete auch für eine reale Berliner Adresse „house number not found“. Der Agent passt nicht, wenn du überwiegend ins Ausland oder nicht mit DHL Paket versendest, oder wenn Aufträge bei dir sofort bestätigt angelegt werden.

Häufige Fragen

Legt die Prüfung bei DHL eine Sendung an oder kostet sie Porto?

Nein, eine Sendung entsteht nicht. Mit validate=true prüft DHL laut eigener Dokumentation nur, speichert nichts, legt keine Sendung an und gibt kein Label zurück. Ob dein DHL-Vertrag API-Aufrufe gesondert berechnet, klärst du mit DHL.

Was passiert mit Packstation- und Postfiliale-Adressen?

Der Agent erkennt „Packstation 123“ oder „Postfiliale 512“ mit Postnummer und schickt sie als solche an DHL; DHL prüft dann die Angaben zur Station. Ist die Angabe nicht eindeutig lesbar, etwa ohne Postnummer, markiert der Agent den Auftrag ohne DHL-Aufruf zur Prüfung.

Prüft der Agent auch Adressen im Ausland?

Nein. Geprüft werden nur Lieferadressen in Deutschland mit DHL Paket national. Aufträge mit anderem Lieferland markiert der Agent als „nicht geprüft“, ohne Kommentar.

Korrigiert der Agent falsche Adressen selbst?

Nein. Er schreibt die Meldungen von DHL als Kommentar an den Auftrag und setzt address needs review. Die Korrektur macht dein Team, meist nach einer Rückfrage bei der Kundin oder dem Kunden.

Hält der Agent Aufträge mit Problemadresse an?

Nein, er markiert sie nur. Sollen nur geprüfte Adressen bestätigt werden, lass in deiner Bestätigungsregel oder deinem Automatisierungs-Flow nur Aufträge mit address check done = ja und address needs review = nein durch.

Kann wals.pro die Einrichtung für mich übernehmen?

Ja, sprich uns an. Im Erstgespräch klären wir, wie dein Auftrags- und Versandprozess aussieht und wie der Agent am besten zu deinem weclapp passt.