APIs und Unternehmensanwendungen integrieren

APIs und Anwendungen integrieren

0:00 n8n bringt Hunderte fertiger Anbindungen mit. Und trotzdem werden Sie früher oder später vor einer Anwendung stehen, für die es keine gibt — die Branchensoftware, die es nur in Ihrem Gewerbe gibt, oder das interne System, das jemand vor zwölf Jahren geschrieben hat. Für genau diesen Fall gibt es einen Baustein, und er ist der vielseitigste im ganzen Werkzeugkasten: den HTTP Request Node.

0:22 Dieses Modul zeigt, wie man ihn beherrscht — und, was mindestens so wichtig ist, wie man verhindert, dass er zum Einfallstor wird.

APIs und Anwendungen integrieren

0:31 Willkommen am zweiten Tag. Es geht heute um das Zusammenspiel mit der Außenwelt und um die Architektur, die daraus folgt. Wir beginnen mit den REST-Grundlagen und dem universellen Baustein. Dann Authentifizierung — der Teil, bei dem man nicht sparen sollte. Danach der Umgang mit großen Datenmengen und mit Grenzen, die fremde Dienste Ihnen setzen.

0:51 Und zum Schluss die Sicherheitsseite: Was passiert eigentlich, wenn die Antwort einer fremden Schnittstelle nicht das enthält, was Sie erwarten?

REST-Grundlagen und HTTP Request Node

1:00 Fangen wir mit dem Baustein an, der jede REST-Schnittstelle ansprechen kann. Wer ihn beherrscht, ist nie darauf angewiesen, dass es für eine Anwendung eine fertige Anbindung gibt. Der HTTP Request Node erlaubt Aufrufe gegen jede Anwendung mit einer REST-Schnittstelle. Sie können ihn als gewöhnlichen Baustein verwenden — oder, und das wird ab Tag vier interessant, einem KI-Agenten als Werkzeug anhängen.

1:24 Ein Hinweis vorweg, den die Dokumentation selbst gibt: Wer diesen Baustein benutzt, baut einen REST-Aufruf. Grundbegriffe von HTTP sind also Voraussetzung, nicht Kür. Das ist der Preis der Universalität — der Baustein nimmt Ihnen die Verbindung ab, aber nicht das Verständnis dafür, was Sie da eigentlich anfragen. Diese Tabelle hat eine dritte Spalte, die in den meisten Übersichten fehlt — und genau sie ist der Grund, warum die Tabelle hier steht.

1:52 Wiederholbarkeit entscheidet nämlich darüber, ob Sie nach einem Fehler einfach noch einmal versuchen dürfen. Ein GET können Sie beliebig oft senden. Ein PUT ersetzt vollständig, das Ergebnis bleibt gleich. Ein DELETE löscht, und was gelöscht ist, bleibt gelöscht. Aber ein POST legt bei jedem Versuch etwas Neues an — zweimal gesendet heißt zwei Vorgänge.

2:13 Behalten Sie diese Spalte im Kopf: Am dritten Tag, wenn wir über Wiederholungsversuche sprechen, entscheidet genau sie. Vier Formate, und die Wahl trifft meist nicht Sie, sondern die Gegenseite. JSON ist der Regelfall bei modernen Schnittstellen. Form URLencoded und Form-Data begegnen Ihnen bei Formularen und Dateianhängen — Form-Data ist das, was ein Browser beim Hochladen schickt.

2:36 Die Option n8n Binary File ist praktisch, wenn eine Datei aus Ihrem Workflow den Rumpf bilden soll; damit reichen Sie einen Anhang direkt weiter, ohne ihn umzukodieren. Und Raw ist der Notausgang für Gegenstellen mit eigenem Format — dort setzen Sie den Content-Type selbst. Wenn etwas nicht funktioniert, lohnt hier der erste Blick.

2:57 Das ist der schnellste Weg zu einer funktionierenden Anbindung, und ich empfehle ihn ausdrücklich. Fast jede API-Dokumentation zeigt einen Beispielaufruf als cURL-Kommando. Sie kopieren ihn, lassen ihn von n8n einlesen — Header, Rumpf, alles wird übernommen — und haben in zehn Sekunden einen Aufruf, der genauso aussieht wie der aus der Dokumentation.

3:17 Danach kommen zwei Schritte, die man nicht überspringen darf: Die Zugangsdaten aus dem importierten Aufruf gehören in ein Credential, und die statischen Werte werden durch Expressions ersetzt. Dann einmal ausführen und die Antwortstruktur ansehen. Genau in dieser Reihenfolge. Der erste Punkt ist die Kehrseite des cURL-Imports: Zugangsdaten bleiben als Klartext im Baustein stehen. Der Import ist bequem, und genau deshalb vergisst man den Aufräumschritt.

3:45 Der zweite ist tückisch, weil er lautlos ist: Der Baustein gibt standardmäßig nur den Rumpf zurück — Statuscode und Header fehlen, bis Sie sie ausdrücklich anfordern. Der dritte ist eine Projektfrage: Es wird gegen die Produktions-API entwickelt, weil die Testumgebung fehlt. Und der vierte: Die Antwort wird als JSON erwartet, kommt aber als Text; dann sieht Ihr Ergebnis aus wie eine Zeichenkette und nicht wie ein Objekt.

Authentifizierung und Credentials

4:10 Jetzt zu dem Teil, bei dem Bequemlichkeit teuer wird. Wie kommt Ihr Workflow an fremde Systeme heran, und wie viel darf er dort eigentlich? Credentials speichern die Angaben zur Anmeldung an einem Dienst — verschlüsselt und getrennt vom Workflow. Die Dokumentation empfiehlt, wo verfügbar den vordefinierten Credential-Typ zu wählen: Er ist einfacher einzurichten und einfacher zu verwalten als eine generisch zusammengestellte Authentifizierung.

4:37 Das ist mehr als ein Komfortargument. Ein vordefinierter Typ weiß, wie der Anbieter tickt — welche Felder er braucht, wie er Tokens erneuert. Bei der generischen Variante bauen Sie das nach, und zwar jedes Mal neu. Nehmen Sie den fertigen Weg, wo es ihn gibt. Für alles andere gibt es diese Liste, und sie sortiert sich nach Alter und Anspruch. Basic Auth und Digest Auth begegnen Ihnen bei älteren, oft internen Schnittstellen.

5:02 Header Auth und Query Auth sind dasselbe in Grün — ein API-Schlüssel, einmal im Header, einmal im Adresszusatz; nehmen Sie im Zweifel den Header, dazu gleich mehr. OAuth in seinen beiden Varianten ist der Standard für delegierten Zugriff, also immer dann, wenn Ihr Workflow im Namen eines Kontos handelt. Und Custom Auth ist der Sammelplatz für alles, was keinem dieser Muster folgt — es gibt mehr davon, als einem lieb ist.

5:27 Bei OAuth 2.0 tauscht der Dienst kein Passwort aus, sondern ein zeitlich begrenztes Token, das nur die vereinbarten Scopes abdeckt. Läuft es ab, holt ein Refresh Token ein neues. Der Vergleich, der hier trägt: Das ist der Hotelschlüssel statt des Generalschlüssels. Er öffnet Ihr Zimmer, nicht die Buchhaltung, und er verliert nach der Abreise seine Gültigkeit.

5:49 Der entscheidende Satz steht am Ende: Die Scopes entscheiden dauerhaft, was ein Workflow im fremden System darf. Sie werden einmal beim Einrichten gewählt — und dann jahrelang nicht mehr angesehen. Genau deshalb lohnt es sich, diese Minute zu investieren. Der erste Punkt ist die direkte Folge: Die Scopes werden großzügig gewählt, weil der Abgleich mit dem tatsächlichen Bedarf Mühe macht. Der Workflow liest — und dürfte löschen.

6:14 Der zweite ist ein Organisationsproblem: Ein Credential wird von vielen Workflows geteilt, und wenn Sie es entziehen müssen, trifft das alle. Der dritte fällt erst nach Monaten auf: Das Refresh Token läuft ab, und niemand hat den Ablauf notiert — dann steht ein Prozess an einem Dienstagmorgen still. Und der vierte ist der Grund für die Empfehlung von eben: Zugangsdaten im URL-Pfad landen in jedem Server-Log, das der Aufruf unterwegs passiert.

Große Datenmengen und API-Limits

6:41 Kommen wir zu dem, was passiert, wenn es nicht mehr um zehn Datensätze geht, sondern um zehntausend. Dann treffen Sie auf zwei Realitäten: Antworten werden geteilt, und Gegenstellen wehren sich. Pagination teilt eine große Ergebnismenge in mehrere Seiten. Der HTTP Request Node kennt dafür zwei Modi, und die Wahl hängt allein davon ab, wie die Gegenseite es macht.

7:03 Entweder zählen Sie selbst hoch — Seite eins, Seite zwei —, dann nehmen Sie den Modus, der einen Parameter je Anfrage verändert. Oder die Antwort liefert die Adresse der nächsten Seite gleich mit, dann folgen Sie einfach dieser Spur. Das zweite ist der bequemere Weg, weil die Gegenseite die Buchführung übernimmt. Welcher gilt, steht in der API-Dokumentation — oder Sie sehen einmal selbst nach, und genau dazu rät die Doku auch.

7:29 Diese vier Variablen sind Ihr Werkzeug beim Einrichten der Paginierung. Die erste zählt mit, wie viele Seiten schon geholt wurden — daraus bauen Sie Abbruchbedingungen. Die anderen drei greifen auf die letzte Antwort zu: auf ihren Rumpf, auf ihre Header, auf den Statuscode. Welche davon Sie brauchen, hängt ganz von der Gegenseite ab; manche legen die nächste Adresse in den Rumpf, andere in einen Link-Header.

7:53 Und deshalb steht unten der wichtigste Satz dieser Folie: Rufen Sie einmal ohne Paginierung auf und sehen Sie sich an, was wirklich zurückkommt. Alles andere ist Raten. Vier Stellschrauben, mit denen Sie freundlich zur Gegenseite bleiben. Batching teilt viele Eingabe-Items in Gruppen — sinnvoll, wenn aus zweihundert Datensätzen sonst zweihundert Aufrufe in einer Sekunde würden.

8:16 Das Batch-Intervall in Millisekunden entschärft eine Ratenbegrenzung, bevor sie zuschlägt. Der Timeout begrenzt, wie lange auf den Antwortbeginn gewartet wird — ohne ihn hängt ein Lauf potenziell ewig. Und Redirects sind standardmäßig eingeschaltet und in der Zahl begrenzbar. Der Gedanke hinter allen vieren: Sie sind Gast bei einem fremden Dienst.

8:36 Ein Gast, der klopft, kommt öfter wieder rein als einer, der hämmert. Der erste Punkt ist der teuerste: Die Paginierung läuft endlos, weil die Abbruchbedingung nie zutrifft. Das merkt man an der Rechnung oder an der Sperrung. Der zweite ist eine Frage des Maßes — alle Seiten holen, obwohl die ersten fünfzig gereicht hätten.

8:56 Der dritte ist der klassische Fehler beim Statuscode 429, also bei einer Ratenbegrenzung: Es wird sofort erneut versucht, statt den Abstand zu vergrößern. Damit verlängern Sie die Sperre, statt sie abzuwarten. Und der vierte: Das Batch-Intervall steht auf null, und die Gegenseite sperrt den Zugang ganz.

Spezialfälle und sichere Verarbeitung

9:15 Zum Abschluss die Sonderfälle — und dann eine Frage, die in Automatisierungs- projekten zu selten gestellt wird: Wie sehr dürfen Sie eigentlich der Antwort einer fremden Schnittstelle vertrauen? Vier Einstellungen, die Sie kennen sollten — zwei davon mit Warnhinweis. GraphQL erwartet die Abfrage im Rumpf, nicht in Pfad und Parametern; das ist nur eine andere Denkweise, kein Problem.

9:37 Include Response Headers and Status liefert Statuscode und Header mit; das brauchen Sie öfter, als die Voreinstellung vermuten lässt. Und jetzt die beiden mit Warnhinweis: Never Error meldet auch bei Fehlercodes im Vierhunderter- und Fünfhunderterbereich Erfolg — dafür gibt es gute Gründe, aber setzen Sie es bewusst. Und Ignore SSL Issues umgeht die Zertifikatsprüfung. Das mag in einem Labor angehen. In Produktion gehört es nicht.

10:05 Es gibt einen eigenen Eintrag im OWASP-Katalog für API-Sicherheit, der genau diesen Fall beschreibt: die unsichere Nutzung fremder APIs. Gemeint ist, dass Daten aus einer Schnittstelle übernommen werden, weil die Quelle als vertrauenswürdig gilt — und dann ungeprüft weitergereicht werden. Der Denkfehler dahinter ist verständlich: Wir prüfen sorgfältig, was Nutzer eingeben, und nehmen für bare Münze, was ein Server antwortet.

10:29 Aber der Server kann kompromittiert sein, er kann sein Format geändert haben, oder er gibt schlicht weiter, was ein Dritter bei ihm eingegeben hat. Vertrauen ist keine Sicherheitsmaßnahme. Diese Tabelle übersetzt die abstrakten Risikobezeichnungen in Dinge, die Sie in einem Workflow tatsächlich sehen. Fehlerhafte Authentifizierung heißt hier ganz konkret: Zugangsdaten stehen im Baustein statt im Credential.

10:54 Unbeschränkter Ressourcenverbrauch heißt: Paginierung ohne Grenze oder ein Aufruf in der Schleife. Server Side Request Forgery — auf den Begriff kommen wir am fünften Tag zurück — heißt: Die Ziel-URL stammt aus eingehenden Daten. Fehlkonfiguration sind genau die beiden Schalter von vorhin. Und unsichere Nutzung fremder APIs heißt: Die Antwort geht ungeprüft ins Zielsystem.

11:17 Fünf Zeilen, fünf konkrete Prüfpunkte. Der erste Punkt ist die gefährlichste Zeile der letzten Tabelle in Aktion: Die URL des Aufrufs wird aus Nutzerdaten zusammengesetzt. Damit bestimmt jemand von außen, wen Ihr Server anruft — und Ihr Server steht im internen Netz. Der zweite ist der Klassiker der Einschleusung: Ein Feld der Antwort wird direkt in eine Datenbankabfrage eingesetzt.

11:40 Der dritte ist ein Betriebsproblem: Die Antwortgröße wird nicht begrenzt, und ein Aufruf zieht hundert Megabyte in den Speicher. Und der vierte ist besonders ärgerlich, weil er aus guter Absicht entsteht: Fehlerantworten werden protokolliert — samt Zugangsdaten im Header.

Übung

11:56 Jetzt binden Sie eine echte fremde Schnittstelle an — mit allem, was dazugehört: Seitenwechsel, Ratenbegrenzung und einem Fehlerfall, den Sie absichtlich herbeiführen. Das Ersatzteilportal Teilehandel stellt Verfügbarkeiten und Preise über eine REST-Schnittstelle bereit — seitenweise und ratenbegrenzt. Beides zusammen ist der Normalfall bei fremden Diensten und genau die Kombination, an der unvorbereitete Workflows scheitern.

12:21 Kesselwerk braucht daraus die verfügbaren Teile zu einer Anlagenbaureihe, aufbereitet für die Einsatzplanung. Klingt nach einer Viertelstunde Arbeit. Die Viertelstunde ist es auch — bis zum ersten Mal zweihundert Teile zurückkommen. Das Lernziel: einen fremden Dienst so einbinden, dass Seitenwechsel, Limits und Fehlerantworten beherrscht sind. Beherrscht heißt hier nicht vermieden, sondern vorgesehen.

12:44 Erfolgreich sind Sie, wenn alle Seiten vollständig geholt werden, eine Ratenbegrenzung zu wachsendem Abstand führt statt zum Abbruch, und ein unerwartetes Antwortformat sichtbar gemeldet wird. Der letzte Punkt ist der, an dem die meisten scheitern — weil ein unerwartetes Format oft aussieht wie ein leeres Ergebnis. Wer früh fertig ist, begrenzt die Gesamtzahl der Seiten und begründet die Grenze. Eine Grenze ohne Begründung ist geraten.

13:10 Eine Stunde, fünf Schritte, und der erste ist der wichtigste: Rufen Sie einmal ohne Paginierung auf und sehen Sie sich die Antwortstruktur an. Erst danach richten Sie irgendetwas ein. Dann OAuth 2.0 mit den kleinstmöglichen Scopes — für diese Aufgabe brauchen Sie ausschließlich Leserechte. Dann die Paginierung passend zum Antwortformat. Dann Batching und Timeout setzen und beobachten, was bei einer Ratenbegrenzung geschieht.

13:34 Und zum Schluss erzwingen Sie einen Fehlerfall und prüfen, was der Workflow daraus macht. Dieser letzte Schritt ist die eigentliche Übung — alles davor ist Vorbereitung. Vier Fallen. Erstens: Die Paginierung wird eingerichtet, bevor jemand die Antwort gesehen hat — dann raten Sie und wundern sich. Zweitens: Der Zugang bekommt Schreibrechte, obwohl nur gelesen wird; das ist der Scope-Stolperstein aus dem zweiten Kapitel, diesmal in Ihrem eigenen Aufbau.

14:02 Drittens, und das ist der schlimmste: Never Error wird gesetzt, damit der Lauf grün bleibt. Damit haben Sie die Fehlerbehandlung nicht gebaut, sondern abgeschafft. Und viertens: Der Abbruch nach der ersten Seite fällt gar nicht auf, weil zwanzig Teile plausibel aussehen. Deshalb zählen Sie am Ende.