Daten von außen

Es gibt genau zwei Richtungen, wie Daten in n8n kommen. Entweder n8n fragt: Es geht ins Internet und holt sich etwas. Das war der Schirmcheck in Teil 3, n8n hat den Wetterdienst gefragt. Der Node dafür heißt HTTP Request.

Oder n8n bekommt etwas zugestellt. Dann ist das andere System aktiv: Ein Shop meldet eine Bestellung, ein Formulardienst meldet, dass jemand etwas ausgefüllt hat. Der Node dafür heißt Webhook, und er ist ein Trigger, weil er den Workflow startet. Kurzer Test für dich: Der Schirmcheck, welche Richtung? Fragen. Ein Shop meldet eine Bestellung? Zugestellt.

So baust du es: Add first step, „Trigger manually“, umbenennen in „Manuell starten“. Dann Plus, Suche „HTTP Request“, umbenennen in „Produkte abrufen“.

Vier Felder, mehr brauchst du nicht. GET steht schon drin. Die URL tippst du ab. Send Query Parameters schaltest du an: Name limit, Value 30. Heißt: Gib mir dreißig Stück, nicht alle. Authentication bleibt auf None, der Dienst will keinen Ausweis. Execute step: Rechts kommt genau ein Item. Antwortet der Dienst nicht, stell im Reiter Settings des Nodes Retry On Fail an.

Jedes Produkt hat rund zwanzig Felder, du brauchst vier. Und hier ist der Trick, mit dem du nichts tippen musst: Add Field, Name produkt. Dann packst du links im Schema title mit der Maus und ziehst es rechts in das Feld Value. n8n schreibt die Expression selbst: {{ $json.title }}, das Feld title aus dem Item, das gerade durchläuft.

Dasselbe dreimal: preis aus price, bewertung aus rating, kategorie aus category. Execute step: immer noch dreißig Items, jetzt mit vier sauberen Feldern. Bleibt preis ein String, steht nach dem Sortieren 9.99 über 100, weil n8n dann Zeichen vergleicht.

Der Filter sieht aus wie der If aus Teil 3, hat aber nur einen Ausgang. Was nicht passt, ist weg. Links ziehst du bewertung aus dem Schema hinein, in der Mitte Number, is greater than or equal to, rechts eine 4. Execute step: Aus dreißig werden ungefähr dreizehn. Die genaue Zahl kann sich ändern, es sind Übungsdaten. Brauchst du die verworfenen Items später noch, nimm einen If.

Sort: Type Simple, Add Field To Sort By, Feld preis, Order Descending, das teuerste oben. Gleiche Zahl wie vorher, nur die Reihenfolge ist neu. Limit: Max Items 5, Keep First Items. Execute step: fünf. Geh danach die Zahlen an den Nodes entlang, von „Produkte abrufen“ bis „Nur die ersten 5“: 1, 30, 30, etwa 13, 13, 5. Diese Zahlen erzählen die ganze Geschichte.

Die Test URL kopierst du oben aus dem Webhook-Node. Sie endet auf webhook-test/mein-postfach. Im Sender stellst du im HTTP Request Send Body an, Body Content Type JSON, Specify Body „Using Fields Below“, und legst drei Felder an: absender, betreff, vorgang. Die Werte ziehst du aus dem Schema von „Nachricht bauen“.

Im Postfach kannst du die Expressions für absender und betreff vorher tippen. Sobald die erste Nachricht da war, ziehst du sie aus dem Schema unter body. Den Webhook-Simulator kannst du vorher durchklicken, ganz ohne n8n.

Diese neun Dinge gehen bei Listen und Webhooks am häufigsten schief. Bei der Liste hilft fast immer derselbe Blick: Zahl am Node lesen, den ersten Node mit falscher Zahl öffnen, Input gegen Output.

Bei Split Out verrät dir die Zahl sogar die Ursache. 0 Items und rechts im Output der Hinweis „The field … wasn't found in any input item“: Der Feldname stimmt nicht, etwa Products statt products. Bleibt es bei 1 Item, gibt es das Feld, aber es steckt keine Liste darin, etwa total. Liefert der Filter 0 Items und bleibt grün, war die Grenze zu hoch. Wird er rot und meldet „Wrong type“, kommt bewertung als Text an. Dann stellst du in „Felder auswählen“ den Typ auf Number.

Beim Webhook ist es meistens die Reihenfolge. Erst lauscht das Postfach, dann sendet der Sender, und zwar innerhalb von zwei Minuten. Danach hört das Postfach von selbst auf. Und die Adresse kopierst du, statt sie abzutippen. Schon ein falscher Buchstabe im Pfad ergibt einen 404.