APIs und Webhooks

Warum APIs und Webhooks?

Workflows und Agenten können nur so viel, wie die Dienste hergeben, mit denen sie verbunden sind. APIs und Webhooks sind diese Verbindungen.

Jedes Mal, wenn n8n Daten von einer Ladestation-API abruft, eine KI-Antwort von Claude anfordert oder eine Nachricht an Telegram sendet, passiert das über eine API oder einen Webhook. Ohne diese Schnittstellen wäre n8n eine Insel – leistungsfähig, aber von der Welt abgeschnitten.

Keine Angst vor Technik:
APIs und Webhooks klingen kompliziert. Das Grundprinzip ist aber einfach – und n8n nimmt einem den größten Teil der technischen Arbeit ab. Wer versteht, was im Hintergrund passiert, baut bessere Workflows und findet Fehler schneller.

Was ist eine API?

↑ Zur Kapitelübersicht

API steht für Application Programming Interface – auf Deutsch: Programmierschnittstelle. Sie ist die definierte Art und Weise, wie ein Programm mit einem anderen kommuniziert.

Stell dir eine API wie die Speisekarte eines Restaurants vor. Das Restaurant (der Dienst) hat eine Küche (seine Daten und Funktionen), die Gäste nicht betreten dürfen. Die Speisekarte (die API) listet auf, was man bestellen kann, in welcher Form und was man dafür bekommt. Man muss nicht wissen, wie das Gericht zubereitet wird – man bestellt, und das Ergebnis kommt zurück.

Was eine API definiert

Endpunkte: URLs, an die Anfragen gestellt werden können. Jeder Endpunkt hat eine klar definierte Aufgabe.
Beispiel: https://api.ladenetz.de/v1/stations liefert eine Liste aller Ladestationen.

Parameter: Zusätzliche Angaben, die die Anfrage präzisieren. Beispiel: ?lat=53.58&lng=10.01&radius=2000 schränkt das Ergebnis auf Stationen im Umkreis von 2 km ein.

Antwortformat: In welcher Form die Daten zurückkommen – fast immer JSON, manchmal XML.

REST-APIs – der Standard im Web

Die meisten öffentlichen APIs folgen dem REST-Prinzip (Representational State Transfer). REST ist keine Technologie, sondern eine Sammlung von Konventionen: Anfragen laufen über HTTP, jeder Endpunkt repräsentiert eine Ressource, und die Antwort enthält den aktuellen Zustand dieser Ressource – ohne dass der Server sich die Anfrage „merkt". In n8n arbeitet der HTTP-Request-Node mit genau diesem Prinzip.

Anfrage und Antwort: wie eine API-Kommunikation abläuft

↑ Zur Kapitelübersicht

Jede API-Kommunikation besteht aus zwei Teilen: einer Anfrage (Request) und einer Antwort (Response).

Die Anfrage (Request)

n8n sendet eine HTTP-Anfrage an den API-Endpunkt. Sie enthält:

Methode: Was soll getan werden? (GET = lesen, POST = senden, siehe nächstes Kapitel)

URL: Welcher Endpunkt wird angesprochen?

Header: Metadaten der Anfrage – z.B. der API-Key zur Authentifizierung und das gewünschte Antwortformat.

Body: Bei POST-Anfragen die eigentlichen Daten, die gesendet werden sollen – als JSON-Text.

Die Antwort (Response)

Der Dienst antwortet mit:

Statuscode: Eine dreistellige Zahl, die angibt ob die Anfrage erfolgreich war.
200 = Erfolg
201 = Erstellt
400 = Fehlerhafte Anfrage
401 = Nicht authentifiziert
404 = Nicht gefunden
429 = Zu viele Anfragen (Rate Limit)
500 = Serverfehler

Body: Die eigentlichen Daten – fast immer als JSON.

Konkretes Beispiel – EV-Ladestation-Abfrage:

Anfrage:
GET https://api.ladenetz.de/v1/stations
?lat=53.58&lng=10.01&radius=1000&status=available
Header: Authorization: Bearer mein-api-key

Antwort (vereinfacht):
Status: 200 OK
{
  "stations": [
    { "id": "HH-042", "name": "Winterhuder Marktplatz",
      "type": "AC", "kw": 22, "available": true },
    { "id": "HH-051", "name": "Barmbeker Straße",
      "type": "DC", "kw": 50, "available": true }
  ]
}

HTTP-Methoden: GET, POST und mehr

↑ Zur Kapitelübersicht

Die HTTP-Methode teilt dem Server mit, was mit der angefragten Ressource getan werden soll.

Methode	Bedeutung	Typischer Einsatz
GET	Daten abrufen	Ladestationen abfragen, Wetterdaten holen, Benutzerprofil lesen
POST	Daten senden / Ressource erstellen	Nachricht an Telegram senden, KI-Anfrage stellen, Formular übermitteln
PUT	Ressource vollständig ersetzen	Datensatz komplett aktualisieren
PATCH	Ressource teilweise ändern	Einzelnes Feld in einem Datensatz aktualisieren
DELETE	Ressource löschen	Eintrag aus Datenbank entfernen

Für den Einstieg reichen GET und POST.
GET für alles, was Daten liest. POST für alles, was Daten sendet oder eine Aktion auslöst. Die meisten Automatisierungsprojekte kommen damit weit.

Authentifizierung: wer darf was?

↑ Zur Kapitelübersicht

Die meisten APIs sind nicht öffentlich zugänglich. Sie verlangen einen Nachweis, dass die anfragende Anwendung berechtigt ist – den API-Key.

Ein API-Key ist ein langer, zufälliger Zeichenstring – vergleichbar mit einem Hausschlüssel. Wer ihn kennt, darf die Tür öffnen. Er wird bei jeder Anfrage mitgesendet, meist im HTTP-Header unter Authorization.

API-Key

Der einfachste und häufigste Authentifizierungstyp. Wird beim Anbieter beantragt (oft kostenlos), in n8n als Credential gespeichert und danach nicht mehr direkt sichtbar.

Beispiel-Header:
Authorization: Bearer sk-abc123xyz...

OAuth 2.0

Wird verwendet, wenn ein Dienst im Namen eines Benutzers handeln soll – z.B. E-Mails aus dem eigenen Gmail-Konto lesen. OAuth erlaubt das, ohne das Passwort an n8n weiterzugeben. Der Benutzer bestätigt den Zugriff einmalig über die Login-Seite des Dienstes. n8n speichert danach einen Token, der den Zugriff erlaubt.

Basic Auth

Benutzername und Passwort werden base64-kodiert im Header mitgesendet. Älteres Verfahren, heute nur noch bei internen Diensten oder einfachen APIs anzutreffen.

Grundregel:
API-Keys niemals in Workflow-Nodes eintragen – immer als n8n-Credential speichern. Details dazu auf der Seite API-Keys verwalten.

Was ist ein Webhook?

↑ Zur Kapitelübersicht

Ein Webhook dreht die Kommunikationsrichtung um: Nicht du fragst den Dienst – der Dienst informiert dich, sobald etwas passiert.

Bei einer normalen API-Abfrage fragt n8n aktiv nach: „Gibt es etwas Neues?" Das kann effizient sein – oder verschwenderisch, wenn man alle 10 Sekunden fragt und die Antwort 99 Mal leer ist.

Ein Webhook löst das anders: Du registrierst eine URL bei dem Dienst – die Webhook-URL deines n8n-Workflows. Sobald beim Dienst ein Ereignis eintritt, sendet er selbst eine POST-Anfrage an diese URL. n8n empfängt sie und startet den Workflow sofort. Keine Wartezeit, kein überflüssiges Abfragen.

Alltags-Analogie

API-Abfrage: Du rufst täglich beim Paketdienst an und fragst: „Ist mein Paket da?"

Webhook: Du hinterlässt deine Nummer, und der Paketdienst ruft dich an, sobald das Paket ankommt.

Wie ein Webhook in n8n aussieht

Der Webhook-Trigger-Node in n8n erzeugt beim Aktivieren eine eindeutige URL:
https://mein-n8n.beispiel.de/webhook/abc123

Diese URL wird beim externen Dienst eingetragen. Von da an sendet der Dienst bei jedem passenden Ereignis eine Anfrage dorthin – und der Workflow startet automatisch.

Typische Webhook-Anwendungen

Neues Formular ausgefüllt → Workflow startet sofort.
Zahlung eingegangen → Bestätigung versenden.
Neuer GitHub-Commit → Benachrichtigung auslösen.
Sensor meldet Grenzwert → Alarm senden.

API vs. Webhook – der Unterschied

↑ Zur Kapitelübersicht

Beide übertragen Daten zwischen Diensten – aber in entgegengesetzter Richtung und zu verschiedenen Zeitpunkten.

Eigenschaft	API-Abfrage	Webhook
Wer fragt an?	n8n fragt den Dienst	Der Dienst informiert n8n
Auslöser	Zeitplan oder manuell	Ereignis beim Dienst
Reaktionszeit	Abhängig vom Abfrageintervall	Sofort bei Ereignis
Ressourcen	Regelmäßige Anfragen auch ohne Neues	Nur bei echtem Ereignis aktiv
Einrichtung	Einfacher, nur URL nötig	URL beim Dienst registrieren
Geeignet für	Regelmäßige Datenabfragen, Berichte	Echtzeit-Reaktionen auf Ereignisse

Faustregel:
Wenn die Frage lautet „Was ist gerade der Stand?" → API-Abfrage.
Wenn die Frage lautet „Informiere mich, sobald etwas passiert" → Webhook.

APIs und Webhooks in n8n

↑ Zur Kapitelübersicht

n8n macht den Umgang mit APIs und Webhooks so einfach wie möglich – die meiste Technik passiert unsichtbar im Hintergrund.

HTTP Request Node – für API-Abfragen

Der universelle Baustein für jede REST-API. Methode wählen, URL eintragen, Header und Parameter konfigurieren, Credential auswählen – fertig. Die Antwort erscheint direkt als JSON-Daten im nächsten Node.

Für bekannte Dienste gibt es oft einen dedizierten Node (z.B. „OpenAI", „Gmail", „Telegram"), der die HTTP-Details vollständig versteckt.

Webhook Trigger Node – für eingehende Ereignisse

Beim Aktivieren erzeugt n8n automatisch eine eindeutige Webhook-URL. Diese URL beim Dienst eintragen – ab dann empfängt n8n alle Ereignisse sofort und startet den Workflow. Der Node zeigt nach dem ersten Empfang die genaue Struktur der empfangenen Daten an, was die Weiterverarbeitung sehr erleichtert.

Respond to Webhook Node – für Antworten

Wenn ein externer Dienst nach dem Senden eine Antwort erwartet – z.B. ein Formular, das nach der Übermittlung eine Bestätigung braucht – sendet dieser Node die Antwort zurück. So kann n8n nicht nur empfangen, sondern auch gezielt antworten.

Praxistipp für den Gitarren-Akkord-Assistenten:
Der Assistent empfängt Anfragen über einen Webhook-Trigger. Eine Texteingabe – „Ich suche etwas Melancholisches in Moll" – kommt als POST-Anfrage an. Der Workflow leitet sie an den KI-Agenten weiter, der antwortet – und Respond to Webhook schickt das Ergebnis sofort zurück an den Aufrufer. Der gesamte Zyklus dauert wenige Sekunden.

Nächste Schritte

↑ Zur Kapitelübersicht

Die Grundlagen sind vollständig. Jetzt geht es an die Praxis: n8n einrichten und den ersten eigenen Workflow bauen.

n8n installieren

Cloud, Docker oder Desktop – die Setup-Seite erklärt alle drei Wege und empfiehlt den schnellsten Einstieg ohne Servererfahrung.

Erster Workflow

Eine laufende n8n-Instanz vorausgesetzt, führt diese Seite durch den ersten vollständigen Workflow – vom leeren Canvas bis zum funktionierenden Ergebnis.

Direkt zum ersten Projekt

Wer lieber mit einem konkreten Ziel lernt: Der EV-Ladesäulen-Finder ist das einsteigerfreundlichste Projekt – eine einfache API-Abfrage, ein Filter, eine Benachrichtigung. Alle Grundlagen dieser Seite kommen dabei direkt zum Einsatz.