Du möchtest automatisch einen neuen Beitrag in WordPress anlegen.

Deine Automatisierung kennt:

Titel,

Text,

Kategorie,

Veröffentlichungsstatus.

Nun könnte ein Programm theoretisch direkt auf die WordPress-Datenbank zugreifen und dort irgendwelche Tabellen verändern.

Das wäre allerdings eine ziemlich schlechte Idee.

Die Anwendung müsste wissen:

welche Tabellen WordPress verwendet,

welche Felder wohin gehören,

welche Nebenwirkungen ein neuer Beitrag besitzt,

wie Berechtigungen funktionieren,

welche internen Regeln WordPress erwartet.

Viel besser ist:

WordPress stellt eine definierte Schnittstelle bereit.

Dein Programm sagt sinngemäß:

Erstelle einen neuen Beitrag.

Titel:
Was ist eine API?

Status:
draft

Inhalt:
...

WordPress nimmt diese Anfrage entgegen, prüft sie und erzeugt den Beitrag auf dem vorgesehenen Weg.

Diese definierte Verbindung zwischen Softwaresystemen nennt man eine API.

API steht für:

Application Programming Interface.

Auf Deutsch ungefähr:

Programmierschnittstelle.

Eine API ist eine vereinbarte Sprache zwischen Programmen

Menschen besitzen Benutzeroberflächen.

Du klickst in WordPress auf:

Beiträge
↓
Erstellen
↓
Veröffentlichen

Software kann keine Maus benötigen.

Sie braucht eine technische Schnittstelle.

Automatisierung
↓
API
↓
WordPress

Eine API definiert:

Welche Aktionen sind möglich?

Welche Daten müssen übergeben werden?

In welchem Format?

Welche Antwort kommt zurück?

Wer darf die Aktion ausführen?

Damit können zwei Programme miteinander arbeiten, ohne die internen Details des jeweils anderen Systems kennen zu müssen.

Eine API ist wie ein kontrollierter Eingang

Stell dir ein Restaurant vor.

Du möchtest ein Essen.

Du gehst nicht:

in die Küche,

öffnest Kühlschränke,

bedienst den Herd

und suchst Zutaten.

Du sprichst mit dem Service.

Gast
↓
Bestellung
↓
Service
↓
Küche

Der Service ist die Schnittstelle.

Du musst nicht wissen:

welcher Koch welches Messer verwendet.

Genauso funktioniert eine API.

Anwendung
↓
API
↓
internes System

Die API versteckt interne Komplexität.

API bedeutet nicht automatisch Web-API

Der Begriff ist breiter.

Auch eine Programmbibliothek kann eine API besitzen.

Zum Beispiel:

calculate_total()

ist eine Funktion, die andere Software verwenden kann.

Ein Betriebssystem besitzt APIs.

Eine Datenbank besitzt APIs.

Eine Bibliothek besitzt APIs.

Im Web meint man mit API aber sehr häufig eine Web-API, die über ein Netzwerk angesprochen wird.

Genau darauf konzentrieren wir uns hier.

Eine Web-API funktioniert häufig über HTTP

HTTP kennen wir bereits aus der Funktionsweise von Websites.

Ein Browser stellt beispielsweise eine Anfrage:

GET /wissen/api/

Der Webserver antwortet.

Dasselbe Prinzip lässt sich für Software verwenden.

Programm
↓
HTTP Request
↓
API
↓
HTTP Response
↓
Programm

Der Unterschied:

Statt einer fertigen HTML-Webseite erhält das Programm häufig strukturierte Daten.

Zum Beispiel JSON.

Eine API-Anfrage heißt Request

Ein Request ist eine Anfrage an eine API.

Zum Beispiel:

Gib mir den Kunden mit der ID 4711.

Technisch könnte das ungefähr aussehen wie:

GET /api/customers/4711

Die API erhält diese Anfrage.

Sie prüft:

Darf der Anfragende diesen Datensatz sehen?

Existiert der Kunde?

Dann erzeugt sie eine Antwort.

Die Antwort heißt Response

Die Antwort könnte sein:

{
  "id": 4711,
  "name": "Anna Muster",
  "status": "active"
}

Damit haben wir das einfachste API-Modell:

Client
↓
Request
↓
Server
↓
Response
↓
Client

Was ist ein Client?

Der Client ist in diesem Zusammenhang das System, das die API aufruft.

Das kann sein:

eine Website,

eine Smartphone-App,

n8n,

ein Python-Skript,

ein WordPress-Plugin,

ein KI-Agent.

Der Client sagt:

Ich möchte etwas von dir.

Der API-Server beantwortet die Anfrage.

Was ist ein Endpoint?

Eine API kann viele Funktionen besitzen.

Jede davon braucht eine Adresse.

Solche Adressen nennt man häufig Endpoints.

Beispielsweise:

/api/customers

für Kunden.

/api/orders

für Bestellungen.

/api/products

für Produkte.

Ein konkreter Kunde könnte erreichbar sein unter:

/api/customers/4711

Der Endpoint beschreibt also:

Welche Ressource beziehungsweise Funktion wird angesprochen?

Eine API besteht häufig aus vielen Endpoints

Ein Shop könnte beispielsweise anbieten:

/products
/orders
/customers
/payments

Damit können externe Programme gezielt auf bestimmte Bereiche zugreifen.

Nicht jede Anwendung bekommt zwangsläufig Zugriff auf alle.

Endpoint und HTTP-Methode ergeben gemeinsam die Aktion

Nehmen wir:

/api/customers/4711

Allein diese URL sagt noch nicht unbedingt, was passieren soll.

Die HTTP-Methode ergänzt die Bedeutung.

GET

kann bedeuten:

Datensatz lesen.

DELETE

kann bedeuten:

Datensatz löschen.

Die Kombination ist entscheidend.

Was bedeutet GET?

GET wird typischerweise verwendet, um Informationen abzurufen.

Zum Beispiel:

GET /api/customers/4711

Bedeutung:

Gib mir Kunde 4711.

Oder:

GET /api/orders

Gib mir Bestellungen.

Ein GET sollte normalerweise keine geschäftliche Veränderung auslösen.

Das macht GET-Anfragen besonders geeignet für Lesezugriffe.

GET-Anfragen können Parameter besitzen

Zum Beispiel:

GET /api/orders?status=open

Nun lautet die Anfrage:

Gib mir nur offene Bestellungen.

Zusätzlich:

GET /api/orders?status=open&customer_id=4711

Nun:

Gib mir offene Bestellungen von Kunde 4711.

Diese Werte hinter dem Fragezeichen nennt man häufig Query-Parameter.

Query-Parameter eignen sich für Filter

Zum Beispiel:

?page=2

?limit=100

?sort=date

?language=de

Damit kann eine API flexibel gesteuert werden, ohne für jede Kombination einen neuen Endpoint zu benötigen.

Was bedeutet POST?

POST wird häufig verwendet, um etwas Neues anzulegen beziehungsweise eine Aktion auszulösen.

Zum Beispiel:

POST /api/customers

Dazu sendet der Client Daten:

{
  "name": "Anna Muster",
  "email": "anna@example.com"
}

Die API erstellt daraus einen neuen Kunden.

Der Response kann den erzeugten Datensatz zurückgeben

Zum Beispiel:

{
  "id": 4711,
  "name": "Anna Muster",
  "email": "anna@example.com"
}

Die wichtige neue Information lautet:

id = 4711

Der Client kann diese ID anschließend für weitere Aktionen verwenden.

Was bedeutet PUT?

PUT wird typischerweise verwendet, um eine Ressource vollständig zu ersetzen beziehungsweise auf einen definierten Zustand zu setzen.

Beispielsweise:

PUT /api/customers/4711

mit:

{
  "name": "Anna Muster",
  "email": "neu@example.com",
  "status": "active"
}

Je nach API kann PUT bedeuten:

Setze den Datensatz auf genau diesen Zustand.

Die genaue Semantik muss allerdings immer aus der Dokumentation der konkreten API gelesen werden.

Was bedeutet PATCH?

PATCH wird häufig verwendet, um nur bestimmte Teile eines Datensatzes zu verändern.

Zum Beispiel:

PATCH /api/customers/4711

mit:

{
  "status": "inactive"
}

Nur der Status wird geändert.

Andere Felder bleiben unberührt.

Das ist besonders praktisch für kleine Änderungen.

Was bedeutet DELETE?

DELETE wird typischerweise zum Entfernen einer Ressource verwendet.

DELETE /api/customers/4711

Bedeutung:

Lösche Kunde 4711.

Ob tatsächlich physisch gelöscht oder nur ein Status wie:

deleted = true

gesetzt wird, hängt vom System ab.

Für den Client zählt zunächst die veröffentlichte API-Semantik.

Die wichtigsten HTTP-Methoden ergeben ein einfaches Modell

GET
→ lesen

POST
→ neu anlegen / Aktion auslösen

PUT
→ ersetzen

PATCH
→ teilweise ändern

DELETE
→ löschen

Das ist eine gute Grundorientierung.

Eine konkrete API kann bestimmte Methoden allerdings anders oder eingeschränkter verwenden.

Die Dokumentation ist daher immer maßgeblich.

CRUD passt gut zu diesem Modell

In Datenanwendungen begegnet häufig das Kürzel CRUD.

Es steht für:

Create
Read
Update
Delete

Also:

Erstellen
Lesen
Ändern
Löschen

Eine typische REST-API bildet diese Funktionen beispielsweise ab über:

POST
GET
PATCH / PUT
DELETE

CRUD und HTTP-Methoden sind nicht dasselbe Konzept.

Sie passen aber häufig gut zusammen.

Was ist REST?

Viele Web-APIs werden als REST APIs bezeichnet.

REST steht für:

Representational State Transfer.

REST ist ein Architekturstil für verteilte Systeme und keine einzelne Programmiersprache.

Für den praktischen Einstieg bedeutet REST häufig:

Ressourcen besitzen URLs,

HTTP-Methoden drücken Aktionen aus,

HTTP-Statuscodes beschreiben Ergebnisse,

Daten werden in standardisierten Repräsentationen übertragen.

Eine Ressource kann ein Kunde sein

Zum Beispiel:

/customers/4711

Oder ein Beitrag:

/posts/172

Oder eine Bestellung:

/orders/98273

Die API behandelt diese Dinge als Ressourcen.

Gute REST-URLs beschreiben eher Dinge als Aktionen

Zum Beispiel:

POST /orders

statt:

/createNewOrderNow

und:

DELETE /orders/4711

statt:

/deleteOrderNumber4711

Die HTTP-Methode trägt einen Teil der Bedeutung.

Das hält API-Strukturen konsistent.

REST ist aber keine zwingende Voraussetzung für APIs

Andere API-Stile existieren ebenfalls.

Zum Beispiel:

GraphQL.

RPC.

SOAP.

WebSocket-basierte Schnittstellen.

Eine API muss nicht REST verwenden.

REST ist lediglich sehr verbreitet.

Was ist GraphQL?

Bei einer klassischen REST-API existieren möglicherweise mehrere Endpoints.

GraphQL verfolgt einen anderen Ansatz.

Der Client beschreibt sehr genau:

Welche Daten brauche ich?

Beispielsweise sinngemäß:

customer 4711
→ name
→ email
→ lastOrders

Der Server liefert genau diese Felder.

Das kann besonders bei komplexen Datenstrukturen praktisch sein.

REST und GraphQL sind keine Qualitätsstufen

Nicht:

REST = alt
GraphQL = modern und besser

Beide besitzen Stärken und Nachteile.

Für viele Automatisierungen ist eine einfache REST-API hervorragend.

Man sollte nicht unnötig Architektur wechseln, nur weil eine andere Technik neuer klingt.

Was ist RPC?

RPC steht für:

Remote Procedure Call.

Dabei wirkt die Schnittstelle stärker wie der Aufruf einer entfernten Funktion.

Zum Beispiel sinngemäß:

sendInvoice(4711)

oder:

calculateShipping(order)

Die Grenze zwischen REST und RPC kann in echten APIs durchaus verschwimmen.

Für Automatisierer ist wichtiger:

Welche Operation bietet die Schnittstelle tatsächlich an?

Was ist SOAP?

SOAP ist ein älterer, aber weiterhin eingesetzter Standard für strukturierte Web-Service-Kommunikation.

SOAP verwendet typischerweise XML und sehr klar definierte Nachrichtenstrukturen.

Man begegnet SOAP besonders in:

älteren Unternehmenssystemen,

Behördenumgebungen,

Banken,

großen ERP-Landschaften.

Wenn ein System funktioniert und SOAP anbietet, muss es nicht allein deshalb ersetzt werden.

Moderne Automatisierung muss unterschiedliche API-Arten verbinden können

Ein Workflow könnte gleichzeitig sprechen mit:

REST API,

SOAP-Service,

Datenbank,

lokaler KI,

Webhook.

Die Workflowengine übersetzt zwischen diesen Systemen.

Das ist einer der Gründe, warum Integrationsplattformen so nützlich sind.

Warum wird bei APIs so häufig JSON verwendet?

JSON ist:

relativ kompakt,

für Menschen lesbar,

einfach maschinell verarbeitbar,

in fast allen Programmiersprachen unterstützt.

Beispiel:

{
  "id": 4711,
  "name": "Anna",
  "active": true
}

Das passt hervorragend zu APIs.

API und Structured Outputs ergänzen sich perfekt

Das haben wir bereits bei strukturierten KI-Ausgaben vorbereitet.

Die KI liefert:

{
  "customer_id": 4711,
  "action": "create_ticket"
}

Die Workflowsoftware verwendet diese Werte anschließend für einen API-Aufruf.

LLM
↓
Structured Output
↓
API
↓
externes System

Das ist eine der wichtigsten Architekturen moderner KI-Automatisierung.

Das Sprachmodell muss die API nicht frei bedienen

Ein schlechter Ansatz wäre:

Hier ist die komplette API-Dokumentation und unser Schlüssel. Mach einfach irgendwas, was du für richtig hältst.

Besser:

LLM
↓
strukturierte Entscheidung
↓
Software prüft
↓
API-Aufruf

Dadurch bleibt die eigentliche technische Kontrolle in normaler Software.

Was enthält ein HTTP-Request?

Ein Request kann mehrere Bestandteile besitzen.

Vereinfacht:

Methode
URL
Header
Body

Zum Beispiel:

POST /api/customers

Header:

Content-Type: application/json

Body:

{
  "name": "Anna"
}

Jeder Teil erfüllt eine andere Aufgabe.

Was sind HTTP-Header?

Header enthalten zusätzliche Informationen zur Anfrage beziehungsweise Antwort.

Zum Beispiel:

Content-Type: application/json

bedeutet:

Der Body enthält JSON.

Oder:

Authorization: ...

übermittelt Authentifizierungsinformationen.

Oder:

Accept: application/json

teilt mit:

Der Client möchte JSON erhalten.

Der Body enthält häufig die eigentlichen Nutzdaten

Bei:

POST
PUT
PATCH

findet man häufig einen Request Body.

Zum Beispiel:

{
  "title": "Was ist eine API?",
  "status": "draft"
}

Bei normalen GET-Anfragen werden Parameter dagegen häufig über URL beziehungsweise Query-Parameter übertragen.

Was ist Content-Type?

Eine API muss wissen, welches Datenformat geschickt wurde.

Zum Beispiel:

Content-Type: application/json

Oder:

Content-Type: application/xml

Oder bei Dateiübertragungen andere Formate.

Wenn der Server JSON erwartet und irgendeinen unstrukturierten Text erhält, kann die Anfrage scheitern.

API-Kommunikation braucht klare Verträge

Die Dokumentation könnte definieren:

Endpoint:

POST /customers

Pflichtfelder:

name
email

Optional:

phone

Antwort:

customer object

Genau diese Klarheit macht APIs automatisierbar.

Was sind HTTP-Statuscodes?

Eine API muss mitteilen:

Hat die Anfrage funktioniert?

Dafür werden unter anderem HTTP-Statuscodes verwendet.

Bekannte Beispiele:

200
201
400
401
403
404
429
500

Die erste Ziffer gibt bereits eine grobe Klasse an.

2xx bedeutet normalerweise Erfolg

Zum Beispiel:

200 OK

Die Anfrage war erfolgreich.

Oder:

201 Created

Eine neue Ressource wurde erfolgreich angelegt.

Ein API-Workflow sollte diese Statuscodes auswerten.

3xx betrifft Weiterleitungen

Zum Beispiel:

301
302

Bei klassischen Webseiten sind Redirects sehr bekannt.

APIs können ebenfalls Weiterleitungen liefern.

Client-Bibliotheken folgen ihnen teilweise automatisch.

Trotzdem sollte man bei unerwarteten Redirects prüfen, warum sie entstehen.

4xx bedeutet normalerweise: Problem mit der Anfrage

Zum Beispiel:

400 Bad Request

Die Anfrage ist ungültig.

Vielleicht:

Pflichtfeld fehlt.

Datentyp falsch.

JSON ungültig.

401 bedeutet typischerweise Authentifizierung fehlt oder ist ungültig

401 Unauthorized

Trotz des Namens geht es in der Praxis häufig darum:

Ich weiß nicht erfolgreich, wer du bist beziehungsweise deine Zugangsdaten sind nicht gültig.

Beispielsweise:

Token abgelaufen.

API-Key falsch.

403 bedeutet häufig: Identität bekannt, aber Aktion nicht erlaubt

403 Forbidden

Zum Beispiel:

Benutzer darf Beiträge lesen,

aber nicht löschen.

Das ist ein wichtiger Unterschied.

401
→ Authentifizierung problematisch

403
→ Berechtigung problematisch

404 bedeutet Ressource nicht gefunden

404 Not Found

Zum Beispiel:

GET /customers/999999

und dieser Datensatz existiert nicht.

Ein Workflow sollte einen 404 nicht automatisch wie einen Serverausfall behandeln.

Vielleicht ist das ein völlig normaler Geschäftszustand.

409 kann auf Konflikte hinweisen

Zum Beispiel:

Ein Datensatz kann nicht angelegt werden, weil eine eindeutige ID bereits existiert.

409 Conflict

Das kann gerade bei automatisierten Imports relevant sein.

Vielleicht versucht der Workflow, denselben Datensatz zweimal zu erzeugen.

422 wird häufig für fachlich ungültige Eingaben verwendet

Beispielsweise:

JSON ist syntaktisch korrekt.

Aber:

email = "abc"

ist keine akzeptierte E-Mail-Adresse.

Nicht jede API verwendet diesen Status gleich.

Darum gilt auch hier:

Dokumentation lesen.

429 bedeutet Rate Limit erreicht

429 Too Many Requests

Der Client hat zu viele Anfragen in zu kurzer Zeit geschickt.

Das ist für Automatisierung besonders wichtig.

Ein Workflow darf nicht einfach noch schneller weiterfeuern.

Er sollte:

warten,

Retry-Regeln beachten,

eventuell Queue verwenden.

5xx bedeutet typischerweise serverseitigen Fehler

Beispiel:

500 Internal Server Error

Der API-Server konnte die Anfrage aufgrund eines internen Problems nicht verarbeiten.

Ein temporärer 500er kann ein Kandidat für einen Retry sein.

Aber auch hier sollten Wiederholungen begrenzt bleiben.

Statuscodes bestimmen die Fehlerstrategie

Ein sinnvoller Workflow könnte ungefähr unterscheiden:

200 / 201
→ Erfolg

400
→ Eingabedaten korrigieren

401
→ Credentials prüfen

403
→ Berechtigung prüfen

404
→ Ressource fehlt

429
→ warten / Rate Limit

500+
→ begrenzter Retry

Damit wird Fehlerbehandlung vorhersehbar.

Man sollte nicht nur auf den Statuscode schauen

Viele APIs liefern zusätzlich einen Response Body.

Beispielsweise:

{
  "error": "email_invalid",
  "message": "The email address is invalid."
}

Der maschinenlesbare Fehlercode:

email_invalid

ist für Automatisierung oft wertvoller als ein langer Text.

Fehlerantworten sollten möglichst strukturiert sein

Eine gute API könnte liefern:

{
  "error": {
    "code": "customer_not_found",
    "field": "customer_id",
    "retryable": false
  }
}

Nun kann ein Workflow exakt reagieren.

Genau dasselbe Prinzip kennen wir aus strukturierten KI-Ausgaben.

Eine API ist selbst eine strukturierte Schnittstelle

Das ist ein hilfreiches Gesamtbild.

Software A
↓
klarer Request
↓
API
↓
klarer Response
↓
Software B

KI-Systeme müssen sich in genau diese Welt einfügen.

Darum sind strukturierte Outputs für KI so wichtig.

Wie authentifiziert sich ein API-Client?

Eine API sollte normalerweise nicht jedem Internetnutzer Zugriff auf alle Daten geben.

Sie muss wissen:

Wer stellt die Anfrage?

Dafür existieren unterschiedliche Authentifizierungsverfahren.

Eine einfache Variante ist:

API-Key.

Was ist ein API-Key?

Ein Anbieter gibt einer Anwendung einen geheimen Schlüssel.

Zum Beispiel sinngemäß:

sk-123456...

Der Client übermittelt ihn bei der Anfrage.

Die API prüft:

Ist dieser Schlüssel gültig?

Wenn ja:

Anfrage zulassen.

API-Keys sollten wie Passwörter behandelt werden

Ein API-Key kann Zugriff auf:

Daten,

Geld,

KI-Kontingente,

Produktionssysteme

ermöglichen.

Deshalb gehört er nicht:

in öffentlichen Quellcode,

in Webseiten-JavaScript, wenn er geheim sein muss,

in Blogartikel,

in Prompts,

in Screenshots.

Secrets gehören in einen Secret Store

Zum Beispiel:

Workflow
↓
Secret Manager
↓
API-Key
↓
API

Der Workflow referenziert den Schlüssel.

Er muss nicht als Klartext in jeder Node stehen.

Das vereinfacht außerdem spätere Rotation.

Was bedeutet Key Rotation?

Ein Schlüssel sollte bei Bedarf ersetzt werden können.

Zum Beispiel:

alter Key
→ deaktivieren

neuer Key
→ verwenden

Wenn der Key an 80 Stellen hart eingetragen wurde, wird Rotation unangenehm.

Mit zentralem Secret Management ändert man ihn an einer Stelle.

API-Keys identifizieren häufig eher Anwendungen als einzelne Nutzer

Für manche Fälle reicht das.

Bei anderen muss eine API wissen:

Welcher konkrete Benutzer hat zugestimmt?

Dann kommen Verfahren wie OAuth ins Spiel.

Was ist OAuth?

OAuth ist ein Rahmenwerk zur delegierten Autorisierung.

Ein bekanntes Alltagsszenario:

Eine Anwendung möchte auf deinen Kalender zugreifen.

Du gibst ihr nicht einfach dein Google-Passwort.

Stattdessen:

Anwendung
↓
fragt um Berechtigung
↓
du meldest dich beim Dienst an
↓
du erlaubst bestimmte Rechte
↓
Anwendung erhält Token

Die Anwendung bekommt dadurch kontrollierten Zugriff.

OAuth trennt Passwort und App-Zugriff

Das ist ein großer Vorteil.

Die Drittanwendung muss dein eigentliches Kontopasswort nicht kennen.

Stattdessen erhält sie einen begrenzten Token.

Dieser kann beispielsweise erlauben:

Kalender lesen

aber nicht:

Gmail löschen

wenn entsprechende Scopes verwendet werden.

Was sind Scopes?

Scopes beschreiben Berechtigungsbereiche.

Beispielsweise:

calendar.read

oder:

calendar.write

Je kleiner die Berechtigung, desto besser.

Das ist wieder das Least-Privilege-Prinzip.

Ein Automatisierungsdienst sollte nur die Rechte bekommen, die er braucht

Wenn ein Workflow nur Beiträge erstellen soll:

Beiträge erstellen

ist ausreichend.

Er braucht möglicherweise keine Rechte für:

Benutzer löschen,

Plugins installieren,

Serverkonfiguration ändern.

Kleine Berechtigungen begrenzen Schäden bei Fehlern.

Tokens können ablaufen

Viele Authentifizierungssysteme verwenden zeitlich begrenzte Access Tokens.

Dann passiert irgendwann:

401

obwohl der Workflow gestern noch funktionierte.

Ein robustes System muss Token-Erneuerung beziehungsweise Refresh-Prozesse unterstützen, wenn das jeweilige Verfahren das vorsieht.

Authentifizierung und Autorisierung sind nicht dasselbe

Authentifizierung beantwortet:

Wer bist du?

Autorisierung:

Was darfst du?

Ein Benutzer kann erfolgreich authentifiziert sein.

Trotzdem darf er vielleicht:

Kunden lesen,

aber nicht löschen.

Diese Trennung ist zentral für APIs.

HTTPS ist für API-Kommunikation praktisch Pflicht

Wenn Zugangsdaten oder sensible Informationen übertragen werden, dürfen sie nicht unverschlüsselt durchs Netzwerk laufen.

Deshalb werden moderne Web-APIs über:

https://

angesprochen.

Unser Artikel SSL und HTTPS verständlich erklärt behandelt die technische Grundlage dafür.

Geheimnisse gehören nicht unnötig in URLs

Eine URL kann in:

Logs,

Browserhistorien,

Proxylogs,

Monitoring

landen.

Deshalb sollten geheime Tokens nicht leichtfertig als Query-Parameter übertragen werden, wenn die API einen sicheren Authentifizierungsheader vorsieht.

Was ist Rate Limiting?

Ein API-Anbieter möchte verhindern:

Ein einzelner Client schickt unbegrenzt viele Anfragen.

Darum kann er definieren:

100 Requests pro Minute

oder:

10.000 pro Tag

Solche Grenzen heißen Rate Limits.

Rate Limits schützen Infrastruktur

Ohne Grenze könnte:

eine fehlerhafte Schleife,

ein Bot,

ein Angreifer

Millionen Requests erzeugen.

Rate Limiting begrenzt diese Last.

Für Automatisierer sind Rate Limits Planungsdaten

Angenommen:

API erlaubt 100 Requests / Minute

Du musst:

100.000 Datensätze

übertragen.

Dann darf der Workflow nicht alles gleichzeitig starten.

Er braucht:

Batching,

Throttling,

Queue.

Manche APIs geben Rate-Limit-Informationen zurück

Zum Beispiel sinngemäß:

Limit: 100
Remaining: 17
Reset: ...

Ein intelligenter Client kann darauf reagieren.

Die genauen Header unterscheiden sich je nach API.

Deshalb gilt:

konkrete Dokumentation beachten.

Was bedeutet Pagination?

Eine API besitzt:

2 Millionen Bestellungen

Ein:

GET /orders

sollte nicht alle zwei Millionen Datensätze gleichzeitig liefern.

Darum werden Ergebnisse auf Seiten aufgeteilt.

Zum Beispiel:

page = 1
limit = 100

Das nennt man Pagination.

Seitenbasierte Pagination

Zum Beispiel:

GET /orders?page=3&per_page=100

Der Client lädt:

Seite 3.

Das ist leicht verständlich.

Bei stark veränderlichen Daten kann Seitenpagination allerdings Probleme verursachen.

Cursor-basierte Pagination

Eine API kann stattdessen einen Cursor zurückgeben.

{
  "data": [...],
  "next_cursor": "abc123"
}

Der nächste Request verwendet:

cursor=abc123

Damit weiß die API:

Wo soll sie fortsetzen?

Für große und sich laufend ändernde Datenmengen kann das robuster sein.

Ein Automatisierungsworkflow muss Pagination bewusst behandeln

Schlecht:

GET /customers
↓
100 Kunden erhalten
↓
fertig

obwohl tatsächlich:

10.000

existieren.

Vielleicht hat die API lediglich die erste Seite geliefert.

Das ist ein klassischer Integrationsfehler.

Pagination sollte bis zum tatsächlichen Ende laufen

Seite 1
↓
weitere vorhanden?
↓
Seite 2
↓
...
↓
keine weitere Seite

Auch dabei muss Rate Limiting berücksichtigt werden.

Große Imports sollten resumierbar sein

Der Workflow verarbeitet:

100.000 Datensätze.

Bei Datensatz 82.341:

Serverausfall.

Schlecht:

morgen wieder bei 1 anfangen.

Besser:

checkpoint = 82.340

und kontrolliert fortsetzen.

Das spart Zeit und verhindert Doppelverarbeitung.

Idempotenz spielt bei APIs eine große Rolle

Wir haben das im Artikel über Automatisierung bereits eingeführt.

Ein Client sendet:

POST /payments

Der Server verarbeitet die Zahlung.

Die Netzwerkverbindung bricht ab, bevor die Antwort ankommt.

Der Client weiß nicht:

Hat die Zahlung funktioniert?

Wenn er dieselbe Anfrage erneut sendet, könnte doppelt bezahlt werden.

Idempotency Keys lösen bestimmte Fälle

Ein Client kann einer Operation eine eindeutige Kennung geben.

Sinngemäß:

Idempotency-Key: order-payment-4711

Der Server merkt:

Diese Operation wurde bereits erfolgreich durchgeführt.

Ein identischer Retry erzeugt keine zweite Zahlung.

Ob eine API solche Mechanismen unterstützt, hängt vom Anbieter ab.

GET sollte typischerweise idempotent sein

Zehnmal:

GET /customers/4711

sollte den Kunden nicht zehnmal verändern.

Lesen verändert die Ressource normalerweise nicht.

PUT und DELETE können ebenfalls idempotente Semantik besitzen

Zweimal:

PUT status = active

führt zum selben Zustand:

active.

Zweimal:

DELETE resource

sollte nicht zwei unterschiedliche Löschungen auslösen.

POST ist dagegen häufig nicht automatisch idempotent.

Das ist bei Retry-Strategien wichtig.

APIs können synchron arbeiten

Client:

POST /reports

Server berechnet Bericht.

Client wartet.

Dann:

{
  "report": "..."
}

Das ist einfach.

Bei langen Aufgaben kann es problematisch werden.

Lange Jobs eignen sich für asynchrone APIs

Client startet:

POST /reports

Antwort:

{
  "job_id": "4711",
  "status": "queued"
}

Nun arbeitet der Server im Hintergrund.

Später:

GET /jobs/4711

Antwort:

{
  "status": "completed",
  "result_url": "..."
}

Das ist robuster für lange Berechnungen.

Noch eleganter: Webhook nach Abschluss

Statt ständig:

Ist Job 4711 fertig?

zu fragen, kann die Anwendung einen Callback beziehungsweise Webhook bereitstellen.

Job fertig
↓
API-Anbieter
↓
Webhook
↓
dein Workflow

Damit sehen wir bereits die direkte Verbindung zum nächsten Artikel.

Was ist ein API-Timeout?

Eine Anfrage läuft.

Nach:

30 Sekunden

noch keine Antwort.

Der Client beendet das Warten.

Das ist ein Timeout.

Ohne Timeouts könnte ein einzelner hängender API-Request einen Workflow sehr lange blockieren.

Timeout bedeutet nicht automatisch, dass serverseitig nichts passiert ist

Das ist wichtig.

Der Client wartet 30 Sekunden.

Timeout.

Der Server hat die Aktion vielleicht bei Sekunde 31 trotzdem abgeschlossen.

Genau deshalb sind:

Idempotenz,

Statusabfragen,

Operation IDs

bei kritischen Aktionen so wichtig.

Netzwerkfehler machen APIs zu verteilten Systemen

Auf einem einzelnen Programmrechner kann eine Funktion entweder:

laufen

oder:

Fehler werfen.

Bei APIs kommt das Netzwerk hinzu.

Vielleicht:

Request angekommen,

Response verloren.

Oder:

Request nie angekommen.

Oder:

Server verarbeitet noch.

Das macht Fehlerbehandlung anspruchsvoller.

Deshalb braucht ein guter API-Client klare Retry-Regeln

Zum Beispiel:

Timeout bei GET
→ vielleicht Retry

500
→ begrenzter Retry

429
→ warten

400
→ kein identischer Retry

POST Zahlung
→ nur mit Idempotenzschutz wiederholen

Ein allgemeines „bei Fehler dreimal wiederholen“ ist nicht immer sicher.

Was bedeutet API-Versionierung?

Eine Schnittstelle lebt.

Heute liefert:

{
  "name": "Anna"
}

Morgen möchte der Anbieter:

{
  "first_name": "Anna",
  "last_name": "Muster"
}

Wenn er die Struktur einfach plötzlich ändert, können tausende Integrationen brechen.

Darum brauchen APIs Versionierungsstrategien.

Version kann Teil der URL sein

Zum Beispiel:

/api/v1/customers

später:

/api/v2/customers

Beide Versionen können eine Zeit lang parallel existieren.

Das gibt Clients Zeit zur Migration.

Nicht jede API verwendet URL-Versionen

Versionierung kann auch über:

Header,

Medientypen,

andere Mechanismen

gelöst werden.

Wichtig ist nicht die konkrete Form.

Sondern:

Änderungen müssen kontrollierbar bleiben.

Breaking Changes sind besonders gefährlich

Ein Feld wird entfernt.

Datentyp ändert sich.

Endpoint verschwindet.

Authentifizierung wird umgestellt.

Bestehende Automatisierungen können sofort ausfallen.

Deshalb sollte man API-Änderungsankündigungen beobachten.

Deprecation bedeutet: Funktion soll künftig verschwinden

Ein Anbieter kann sagen:

Endpoint X ist deprecated.

Das bedeutet nicht unbedingt:

Er funktioniert heute nicht mehr.

Sondern:

Man sollte auf die neue Variante migrieren.

Automatisierungen sollten solche Warnungen nicht jahrelang ignorieren.

API-Versionen gehören ins technische Inventar

Für einen Workflow sollte bekannt sein:

Dienst:
CRM

API:
v3

Endpoint:
...

Authentifizierung:
OAuth

Verantwortlich:
...

Bei hundert Integrationen wird solches Inventar sehr wertvoll.

Was ist eine API-Dokumentation?

Sie beschreibt beispielsweise:

Endpoints,

Methoden,

Parameter,

Datenmodelle,

Authentifizierung,

Fehlercodes,

Rate Limits,

Beispiele.

Ohne gute Dokumentation wird Integration unnötig schwierig.

Gute API-Dokumentation enthält konkrete Beispiele

Zum Beispiel:

POST /customers

Request:

{
  "name": "Anna"
}

Response:

{
  "id": 4711,
  "name": "Anna"
}

Ein Entwickler kann damit sehr schnell beginnen.

Was ist OpenAPI?

OpenAPI ist eine standardisierte Beschreibung für HTTP-basierte APIs.

Damit kann maschinenlesbar dokumentiert werden:

welche Endpoints existieren,

welche Parameter erlaubt sind,

welche Datenmodelle verwendet werden,

welche Antworten möglich sind.

Das eröffnet viele Möglichkeiten.

Aus einer OpenAPI-Beschreibung können Werkzeuge erzeugt werden

Zum Beispiel:

interaktive Dokumentation,

Client-Code,

Server-Stubs,

Tests,

Validierung.

Eine API-Beschreibung wird damit nicht nur Text für Menschen.

Sondern eine maschinenlesbare Spezifikation.

OpenAPI passt hervorragend zu KI-Tools

Ein Agent muss wissen:

Welche Funktion existiert?

Welche Parameter?

Welche Datentypen?

Eine strukturierte API-Beschreibung kann dabei helfen, solche Werkzeuge kontrolliert bereitzustellen.

Das heißt nicht:

Jede OpenAPI-Schnittstelle sollte automatisch einem Agenten gegeben werden.

Berechtigungen bleiben entscheidend.

Was ist CORS?

Wenn eine Webseite im Browser direkt eine API auf einer anderen Domain aufrufen möchte, greift ein Sicherheitsmechanismus des Browsers namens:

Cross-Origin Resource Sharing, kurz CORS.

Beispiel:

frontend.example.com
↓
api.other-service.com

Der API-Server muss festlegen, ob solche Browserzugriffe erlaubt sind.

CORS ist hauptsächlich ein Browserproblem

Ein Server-to-Server-Workflow wie n8n oder Python ist nicht in derselben Weise von Browser-CORS-Regeln betroffen.

Das ist wichtig.

Viele Nutzer sehen:

CORS error

und denken:

Die API ist kaputt.

Vielleicht funktioniert die API serverseitig problemlos.

Nur der Browser blockiert den direkten Cross-Origin-Zugriff.

Geheime API-Keys gehören oft ohnehin nicht in Browsercode

Wenn eine API einen privaten Schlüssel verlangt:

Browser
↓
geheimer API-Key

wäre problematisch.

Jeder Nutzer könnte den Schlüssel möglicherweise auslesen.

Besser:

Browser
↓
eigener Backendserver
↓
geheimer API-Key
↓
externe API

Das Backend schützt das Secret.

Server-to-Server-APIs sind für Automatisierung besonders wichtig

n8n:

n8n
↓
API
↓
CRM

Hier läuft alles auf Servern.

Kein Browser muss beteiligt sein.

Dadurch sind viele Integrationen einfacher und sicherer umzusetzen.

APIs können Dateien übertragen

Nicht jede API transportiert nur JSON.

Eine Anwendung könnte:

PDF hochladen,

Bild herunterladen,

CSV exportieren.

Dafür existieren entsprechende Content-Types und Upload-Verfahren.

Der Workflow muss wissen:

Handelt es sich um strukturierte Daten oder Binärdateien?

Datei-Metadaten sollten separat behandelt werden

Zum Beispiel:

{
  "filename": "rechnung.pdf",
  "content_type": "application/pdf",
  "size": 183742
}

Die eigentlichen Dateibytes werden vielleicht separat übertragen.

Das ist häufig sauberer als riesige Dateien als Text in JSON einzubetten.

Was bedeutet Base64?

Binärdaten können in eine Textdarstellung namens Base64 umgewandelt werden.

Dann könnten sie theoretisch innerhalb eines JSON-Feldes übertragen werden.

Das vergrößert die Daten jedoch.

Für große Dateien sind direkte Upload- beziehungsweise Downloadmechanismen häufig besser.

APIs können Suchfunktionen anbieten

Beispiel:

GET /articles?query=caching

oder:

POST /search

mit komplexeren Parametern.

Eine semantische Suche kann damit ebenfalls als API angeboten werden.

RAG besteht oft aus mehreren APIs

Beispielsweise:

Nutzerfrage
↓
Embedding API
↓
Vector Search API
↓
Dokument API
↓
LLM API
↓
Antwort

Oder alles läuft lokal innerhalb eines Systems.

Für den Workflow ist entscheidend:

Welche Schnittstellen stehen zur Verfügung?

Eine lokale KI kann ebenfalls eine API anbieten

Das ist sehr wichtig.

Ein lokal laufendes Sprachmodell muss nicht direkt in n8n eingebaut werden.

Es kann eine HTTP-Schnittstelle bereitstellen.

n8n
↓
HTTP
↓
lokaler KI-Server
↓
Antwort

Dadurch wird lokale KI genauso integrierbar wie ein Cloudmodell.

Das schafft Austauschbarkeit

Heute:

Workflow
↓
Cloud-KI-API

morgen:

Workflow
↓
lokale KI-API

Wenn beide über eine vergleichbare interne Schnittstelle angesprochen werden, muss der Workflow nicht vollständig neu gebaut werden.

Ein interner API-Adapter kann Anbieterunterschiede verstecken

Zum Beispiel:

Workflow
↓
/internal/llm
↓
Adapter
│
├── Anbieter A
├── Anbieter B
└── lokales Modell

Der Workflow kennt nur:

/internal/llm

Das reduziert Anbieterabhängigkeit.

APIs sind damit auch Abstraktionsschichten

Die Anwendung muss nicht wissen:

Welche Datenbank?

Welcher Modellanbieter?

Welche interne Programmiersprache?

Sie kennt nur den Vertrag:

Request rein
Response raus

Das macht Systeme austauschbarer.

APIs können sehr kleine Funktionen kapseln

Zum Beispiel:

POST /normalize-address

Eingabe:

{
  "address": "..."
}

Ausgabe:

{
  "street": "...",
  "postal_code": "...",
  "city": "..."
}

Solche kleinen Services können wiederverwendbare Bausteine einer Automatisierungsplattform werden.

Eine API sollte möglichst eine klare Verantwortung besitzen

Schlecht:

POST /doEverything

mit 80 Optionen.

Besser:

klar definierte Ressourcen beziehungsweise Funktionen.

Das erleichtert:

Tests,

Berechtigungen,

Dokumentation,

Fehlerbehandlung.

API-Design und Workflow-Design ähneln sich

Beide profitieren von:

kleinen Verantwortungsbereichen,

klaren Datenmodellen,

eindeutigen Zuständen,

stabilen Schnittstellen.

Eine chaotische API erzeugt chaotische Automatisierungen.

Ein häufiger Fehler: Datenbank direkt statt API verwenden

Wenn zwei eigene Systeme unter vollständiger Kontrolle stehen, kann direkter Datenbankzugriff manchmal sinnvoll sein.

Bei fremder Software ist er oft problematisch.

Warum?

Die interne Datenbankstruktur ist keine garantierte Schnittstelle.

Ein Update kann Tabellen verändern.

Die API ist dagegen genau dafür gedacht:

externe Programme anzubinden.

WordPress ist ein gutes Beispiel

Man könnte einen Beitrag theoretisch direkt in:

wp_posts

schreiben.

Aber WordPress besitzt mehr Logik als nur eine Tabellenzeile.

Es gibt:

Metadaten,

Hooks,

Revisionen,

Berechtigungen,

Caches,

Plugins.

Der vorgesehene Programmpfad ist deshalb meist besser.

WordPress besitzt eine REST API

Über die WordPress REST API können Inhalte programmgesteuert gelesen und – bei entsprechender Authentifizierung und Berechtigung – verändert werden.

Ein typischer API-Pfad sieht konzeptionell aus wie:

/wp-json/wp/v2/posts

Damit können Anwendungen Beiträge als strukturierte Daten abrufen beziehungsweise erstellen.

Einen WordPress-Beitrag über API anlegen

Ein automatisierter Prozess könnte beispielsweise senden:

{
  "title": "Was ist eine API?",
  "content": "<p>...</p>",
  "status": "draft"
}

WordPress erzeugt daraus einen Entwurf.

Der Workflow muss nicht:

Browser öffnen,

wp-admin laden,

Felder anklicken.

Das ist für Content-Automatisierung enorm wertvoll

Ein Workflow könnte:

Thema
↓
Recherche
↓
Text
↓
Qualitätsprüfung
↓
WordPress REST API
↓
Entwurf

Damit entsteht ein Artikel bereits im CMS.

Ein Mensch kann ihn anschließend prüfen und veröffentlichen.

Kategorien können ebenfalls als IDs übergeben werden

Angenommen:

Kategorie-ID 17
→ KI & Automatisierung

Dann kann der Workflow:

{
  "categories": [17]
}

übergeben.

Das ist besser, als die KI raten zu lassen:

Wie heißt die Kategorie vermutlich genau?

Wieder gilt:

IDs aus dem CMS.

Nicht erfinden.

Medien können ebenfalls automatisiert verarbeitet werden

Ein Prozess könnte:

Bild erzeugen beziehungsweise auswählen,

Bild hochladen,

Media-ID erhalten,

diese ID dem Beitrag zuweisen.

Bild
↓
WordPress Media API
↓
media_id
↓
Beitrag

Solche Prozesse bestehen meist aus mehreren API-Aufrufen.

API-Aufrufe sollten Ergebnisse weiterreichen

Beispiel:

Schritt 1:

POST image

Response:

{
  "id": 821
}

Schritt 2 verwendet:

featured_media = 821

Das ist ein typischer Workflow.

Jeder Schritt erzeugt strukturierte Daten für den nächsten.

Fehlgeschlagene Zwischenschritte müssen gestoppt werden

Bild-Upload scheitert.

Trotzdem veröffentlicht der Workflow den Artikel mit einer erfundenen Media-ID.

Schlecht.

Besser:

Upload fehlgeschlagen
↓
Workflow stoppen oder ohne Bild fortsetzen,
wenn ausdrücklich erlaubt

Der Fehlerpfad muss vorher definiert sein.

API-Antworten sollten nie ungeprüft verwendet werden

Ein Endpoint liefert:

{
  "status": "error"
}

HTTP-Code aber vielleicht trotzdem 200.

Solche APIs existieren.

Daher muss die Dokumentation berücksichtigt werden.

Manche Systeme signalisieren Fehler:

über HTTP-Code,

andere zusätzlich:

über Body-Felder.

API-Wrapper können schlechte externe Schnittstellen verbessern

Wenn eine Drittanbieter-API unpraktisch ist, kann ein eigener interner Service davor geschaltet werden.

Workflow
↓
eigene saubere API
↓
komische Fremd-API

Der Wrapper übersetzt:

Datenformate,

Fehlercodes,

Authentifizierung.

Der Rest des Systems bleibt sauber.

APIs sollten geloggt werden – aber nicht blind vollständig

Logging kann erfassen:

Endpoint.

Statuscode.

Laufzeit.

Request-ID.

Aber Vorsicht:

Request- oder Response-Bodies können enthalten:

Passwörter,

Tokens,

personenbezogene Daten.

Logs dürfen nicht versehentlich zum Datenleck werden.

Secrets müssen aus Logs entfernt werden

Zum Beispiel:

Authorization: Bearer ***

statt:

komplettes Token.

Auch Kreditkartendaten oder sensible Kundendaten sollten nicht unnötig in Debug-Logs landen.

Eine Request-ID hilft bei Fehlersuche

Der API-Anbieter liefert beispielsweise:

request_id = abc123

Support kann dann genau diese Anfrage finden.

Auch dein eigener Workflow sollte möglichst mit:

Correlation IDs

arbeiten.

Das verbindet Logs über mehrere Systeme hinweg.

APIs brauchen Monitoring

Interessante Kennzahlen:

Requests pro Minute

Erfolgsrate

4xx-Rate

5xx-Rate

P95-Latenz

Rate-Limit-Fehler

Damit erkennt man:

Funktioniert die Integration?

Ein plötzlicher Anstieg von 401-Fehlern hat eine andere Ursache als 500er

401 steigt
→ wahrscheinlich Authentifizierung

429 steigt
→ Rate-Limit / Last

500 steigt
→ Serverproblem

Monitoring beschleunigt Diagnose erheblich.

APIs können Verträge mit Service-Leveln besitzen

Ein Anbieter verspricht vielleicht:

bestimmte Verfügbarkeit,

bestimmte Antwortzeiten,

bestimmte Kontingente.

Für geschäftskritische Automatisierungen sollte man prüfen:

Was passiert bei Ausfall?

Existiert Ersatz?

Kann der Workflow später nacharbeiten?

Externe APIs sind Abhängigkeiten

Wenn dein gesamter Prozess von einem SaaS-Dienst abhängt:

Dienst offline

→ Workflow steht.

Deshalb sollte man Abhängigkeiten bewusst dokumentieren.

Content Workflow
abhängig von:
- Recherche API
- LLM API
- WordPress API

Nun ist klar, wo Fehler entstehen können.

Circuit Breaker können bei wiederholten API-Ausfällen helfen

Stell dir vor, ein Dienst ist offline.

Tausend Jobs versuchen jede Sekunde erneut.

Das verschärft die Situation.

Ein Circuit Breaker kann sinngemäß sagen:

zu viele Fehler
↓
vorübergehend keine neuen Requests
↓
nach Wartezeit vorsichtig erneut testen

Das schützt beide Systeme.

API-Aufrufe sollten oft über zentrale Komponenten laufen

Wenn 50 Workflows denselben Dienst nutzen, ist es unpraktisch, überall:

Authentifizierung,

Retrylogik,

Rate-Limit-Handling

neu zu bauen.

Besser:

eine wiederverwendbare Integrationskomponente.

Ein CRM-Connector könnte beispielsweise kapseln

find_customer()

create_customer()

update_customer()

create_note()

Die darunterliegende API kann sich ändern.

Die Workflows verwenden weiterhin dieselben internen Funktionen.

Das macht Systeme wartbarer.

APIs ermöglichen Tool Calling für Sprachmodelle

Ein Sprachmodell kann eine Anfrage verstehen:

Wie viele offene Rechnungen hat Anna?

Das Modell sollte diese Zahl nicht erraten.

Stattdessen:

{
  "tool": "get_open_invoices",
  "customer_id": 4711
}

Die Anwendung führt einen API-Aufruf aus.

Die API liefert reale Daten

{
  "open_invoices": 3,
  "total_amount": 428.70,
  "currency": "EUR"
}

Das LLM formuliert:

Anna hat derzeit drei offene Rechnungen mit insgesamt 428,70 Euro.

Damit kommt der Fakt aus der Datenquelle.

Das Sprachmodell übernimmt Sprache und Interpretation.

Das ist wesentlich robuster als Modellgedächtnis

LLM-Wissen
→ möglicherweise veraltet

API
→ aktueller Systemzustand

Für operative Informationen sollte die API häufig die Source of Truth sein.

Tool Calling sollte erlaubte Funktionen begrenzen

Ein Finanzassistent braucht vielleicht:

get_balance
get_transactions

Nicht automatisch:

transfer_all_money

Die API-Schicht bietet nur Funktionen an, die der konkrete Assistent benötigt.

APIs können Berechtigungen pro Tool erzwingen

Selbst wenn das LLM versucht:

delete_customer

und dieses Tool existiert nicht:

keine Aktion.

Wenn Tool existiert, prüft API trotzdem:

Darf dieser Benutzer löschen?

Damit entsteht Defense in Depth.

KI-Agenten werden dadurch erst praktisch

Ein Agent ohne Werkzeuge kann hauptsächlich:

denken,

schreiben,

planen.

Mit APIs kann er:

Kalender lesen,

Dokumente suchen,

CRM abfragen,

Tickets erstellen.

Das erhöht seine Fähigkeiten erheblich.

Aber auch sein Risiko.

Darum ist API-Design Agentensicherheit

Wenn APIs:

zu mächtig,

schlecht berechtigt,

unklar

sind, wird ein Agent schwer kontrollierbar.

Kleine, klar begrenzte Tools sind sicherer.

Zum Beispiel:

create_email_draft

ist sicherer als:

send_any_email_to_anyone

wenn menschliche Freigabe gewünscht ist.

Ein API-Tool kann zunächst nur einen Entwurf erzeugen

KI
↓
create_draft
↓
Mensch prüft
↓
send

Das ist ein sehr starkes Automatisierungsmuster.

Die API unterstützt dabei bewusst den Freigabeprozess.

Gute APIs machen sichere Prozesse einfacher

Wenn eine Schnittstelle bereits Funktionen besitzt wie:

draft
approve
execute

kann ein Workflow diese Zustände sauber abbilden.

Eine einzige Funktion:

do_everything

macht Kontrolle schwieriger.

APIs sollten Eingaben serverseitig validieren

Ein Client sendet:

{
  "amount": -500
}

Selbst wenn die Clientsoftware diesen Wert normalerweise verhindert:

Der Server muss ihn trotzdem prüfen.

Warum?

Clients können:

Fehler haben,

manipuliert werden,

anders implementiert sein.

Die API ist eine Vertrauensgrenze.

Niemals nur auf Client-Validierung verlassen

Frontend sagt:

Betrag maximal 10.000.

Ein Angreifer ruft API direkt auf:

{
  "amount": 100000000
}

Wenn Server nicht prüft:

Problem.

Alle kritischen Regeln gehören serverseitig erzwungen.

Dasselbe gilt bei KI

Das Modell liefert strukturiert:

{
  "refund_amount": 100000
}

Die API muss selbst prüfen:

Darf dieser Betrag erstattet werden?

Wer hat freigegeben?

Existiert die Zahlung?

KI-Ausgaben sind Input.

Nicht Wahrheit.

API-Validierung und Structured Output ergänzen sich

LLM
↓
Schema-konforme Daten
↓
API
↓
erneute fachliche Validierung

Das ist keine unnötige Doppelarbeit.

Jede Ebene schützt ihre eigene Grenze.

Eine API sollte keine internen Fehlerdetails verraten

Schlecht:

SQL password = ...
Stack trace ...
internal path ...

in einer öffentlichen Fehlermeldung.

Besser:

{
  "error": "internal_error",
  "request_id": "abc123"
}

Die technischen Details bleiben in internen Logs.

API-Sicherheit umfasst mehr als Authentifizierung

Weitere Themen:

Berechtigungen,

Input Validation,

Rate Limits,

Logging,

Netzwerkzugriff,

HTTPS,

Secret Management.

APIs sind attraktive Angriffsflächen, weil sie direkt Funktionen eines Systems zugänglich machen.

Private APIs können Netzwerkzugriff begrenzen

Eine interne Service-API muss vielleicht gar nicht öffentlich im Internet erreichbar sein.

internes Netzwerk
↓
API

statt:

gesamtes Internet
↓
API

Das reduziert die Angriffsfläche.

Lokale KI-APIs sollten ebenfalls nicht unnötig offen sein

Ein lokal laufendes Modell könnte theoretisch erreichbar sein über:

0.0.0.0:Port

Wenn Firewall und Authentifizierung fehlen, kann daraus ein öffentlich erreichbarer Dienst werden.

Auch lokale APIs brauchen saubere Netzwerksicherheit.

Eine API ist nicht automatisch sicher, nur weil sie „intern“ heißt

Ein kompromittierter interner Rechner kann ebenfalls auf Dienste zugreifen.

Deshalb bleiben:

Authentifizierung,

Autorisierung,

Logging

sinnvoll.

APIs können über Reverse Proxies geschützt werden

Ein Reverse Proxy kann beispielsweise übernehmen:

TLS.

Authentifizierung.

Rate Limiting.

Logging.

Routing.

Dann liegen mehrere interne Dienste hinter einer kontrollierten Eingangsschicht.

Das kann lokale KI-Infrastruktur übersichtlicher machen.

API-Gateways gehen noch weiter

Ein API-Gateway kann zentral verwalten:

Authentifizierung,

Rate Limits,

Versionen,

Routing,

Monitoring.

Bei wenigen eigenen Diensten kann das Overkill sein.

Bei vielen Microservices wird es interessanter.

Microservices kommunizieren häufig über APIs

Statt einer großen Anwendung existieren getrennte Services:

User Service
Order Service
Payment Service
AI Service

Sie kommunizieren über Schnittstellen.

Das erhöht Modularität.

Aber auch:

Netzwerkkomplexität,

Monitoringbedarf,

Fehlerfälle.

Microservices sind daher kein automatisches Qualitätsmerkmal.

Für kleine Systeme ist ein Monolith häufig völlig ausreichend

Eine Anwendung kann:

Datenbank,

Logik,

API

in einem Projekt enthalten.

Das kann einfacher zu betreiben sein.

Eine API kann trotzdem nach außen eine saubere Schnittstelle anbieten.

Architektur sollte der tatsächlichen Größe folgen.

Was bedeutet SDK?

Ein API-Anbieter kann zusätzlich eine Softwarebibliothek anbieten.

Beispielsweise für:

Python,

JavaScript,

PHP.

Diese Bibliothek nennt man häufig SDK, Software Development Kit.

Statt HTTP manuell zu bauen:

POST ...
Header ...
JSON ...

kann man schreiben:

client.create_customer(...)

Das SDK erledigt die Details.

SDK und API sind nicht dasselbe

API:

technische Schnittstelle.

SDK:

Hilfswerkzeug für Entwickler, um diese Schnittstelle leichter zu verwenden.

Wenn das SDK schlecht oder nicht verfügbar ist, kann die API oft weiterhin direkt angesprochen werden.

Für n8n braucht man häufig gar kein SDK

Viele Dienste besitzen fertige Nodes.

Wenn nicht:

HTTP Request Node.

Damit können REST-APIs direkt verwendet werden.

Das macht offene APIs besonders wertvoll.

Eine API kann dadurch Dienste integrierbar machen, die n8n nicht direkt kennt

Solange dokumentiert ist:

URL.

Methode.

Authentifizierung.

Request.

Response.

kann ein generischer HTTP-Client ausreichen.

Das ist ein wichtiger Vorteil offener Webstandards.

APIs ermöglichen Automatisierung unabhängig von Benutzeroberflächen

Weboberflächen ändern sich:

Button verschoben.

HTML neu gestaltet.

CSS-Klasse geändert.

Eine Browserautomation kann daran brechen.

Eine stabile API bleibt möglicherweise unverändert.

Deshalb ist API-basierte Integration häufig robuster als Screen Scraping.

Browserautomation hat trotzdem ihren Platz

Manche Systeme besitzen keine API.

Dann kann ein Browserbot:

klicken,

Formulare ausfüllen,

Daten ablesen.

Das ist möglich.

Aber meistens fragiler.

Wenn eine ordentliche API existiert:

bevorzugen.

Was ist Scraping im Vergleich zur API?

Scraping:

Webseite für Menschen
↓
Information herauslesen

API:

Schnittstelle für Programme
↓
strukturierte Information

Die API ist normalerweise die sauberere Datenquelle.

Eine API kann jedoch eingeschränkter sein als die Benutzeroberfläche

Manchmal kann der Mensch in der Webanwendung eine Funktion nutzen, die API bietet sie aber nicht an.

Dann muss entschieden werden:

API erweitern?

anderes Integrationsverfahren?

manueller Schritt?

Nicht jede Funktion ist automatisch automatisierbar.

API-Zugriff kann kostenpflichtig sein

Ein Produkt kann anbieten:

kostenlose Weboberfläche,

aber:

API nur in höherem Tarif.

Für Automatisierungsplanung sollte daher früh geprüft werden:

Existiert API?

Welche Funktionen?

Welche Limits?

Welche Kosten?

Kosten skalieren mit automatisierter Nutzung

Eine Anfrage kostet vielleicht:

0,001 Euro.

Bei:

10 Millionen Requests

wird das relevant.

Deshalb gehören API-Gebühren in die Wirtschaftlichkeitsrechnung eines Workflows.

Caching kann API-Aufrufe reduzieren

Eine Information ändert sich nur einmal täglich.

Workflow fragt sie:

100.000-mal.

Besser:

API
↓
einmal abrufen
↓
Cache
↓
wiederverwenden

Das spart:

Kosten,

Latenz,

Rate-Limit-Kontingent.

Aber Cache braucht Aktualisierungsregeln

Preis geändert.

Cache zeigt alten Preis.

Damit entsteht wieder das bekannte Problem:

Performance
↔
Aktualität

Der Artikel Caching einfach erklärt behandelt dieses Grundprinzip ausführlich.

Webhooks können Cache-Aktualisierung auslösen

Beispiel:

Produkt geändert.

Quellsystem sendet:

Webhook.

Workflow:

Produktänderung
↓
Cache invalidieren

Damit müssen wir nicht ständig pollen.

Das ist eine elegante Kombination aus:

API,

Webhook,

Cache.

APIs sind häufig für Abruf und Aktionen zuständig

API
→ Frag mich etwas

Webhooks:

Webhook
→ Ich sage dir von selbst,
   dass etwas passiert ist

Diese beiden Konzepte ergänzen sich hervorragend.

Ein Beispiel: Shop und CRM

Neue Bestellung.

Shop sendet Webhook:

order.created

Workflow erhält:

order_id = 4711

Nun verwendet Workflow die Shop-API:

GET /orders/4711

und lädt die vollständigen Bestelldaten.

Danach verwendet er CRM-API:

POST /customers

oder:

PATCH /customers/...

Webhook startet.

APIs erledigen die Kommunikation.

Genau deshalb folgt nach APIs logischerweise Webhooks

Die beiden Begriffe gehören zusammen, sollten aber nicht verwechselt werden.

API:

Client initiiert Kommunikation.

Webhook:

Quellsystem initiiert Benachrichtigung.

Dieses Muster ist die Grundlage sehr vieler Automatisierungen.

Was du dir über APIs merken solltest

Eine API ist eine definierte Schnittstelle, über die Software mit anderer Software kommunizieren kann.

Statt interne Datenbanken oder Benutzeroberflächen direkt zu manipulieren:

Anwendung
↓
API
↓
anderes System

Die API definiert:

welche Funktionen verfügbar sind

welche Daten erwartet werden

wie Daten übertragen werden

wie Fehler aussehen

wer welche Aktionen ausführen darf

Bei Web-APIs erfolgt die Kommunikation häufig über HTTP.

Das Grundmodell lautet:

Client
↓
Request
↓
API-Server
↓
Response
↓
Client

Ein Endpoint bezeichnet dabei einen konkreten API-Zugriffspunkt.

Zum Beispiel:

/customers/4711

HTTP-Methoden drücken häufig die gewünschte Operation aus.

GET
→ lesen

POST
→ erstellen / Aktion auslösen

PUT
→ ersetzen

PATCH
→ teilweise ändern

DELETE
→ entfernen

Daten werden häufig als JSON übertragen.

{
  "id": 4711,
  "status": "active"
}

Damit passen APIs perfekt zu strukturierten KI-Ausgaben.

Freitext
↓
LLM
↓
strukturierte Daten
↓
API
↓
reales System

HTTP-Statuscodes zeigen, wie eine Anfrage verlaufen ist.

2xx
→ Erfolg

4xx
→ Problem mit Anfrage,
   Authentifizierung oder Berechtigung

5xx
→ serverseitiges Problem

Wichtige Einzelfälle sind beispielsweise:

401
→ Authentifizierung

403
→ Berechtigung

404
→ Ressource fehlt

429
→ Rate Limit

500
→ Serverfehler

Ein robuster Workflow behandelt diese Fehler unterschiedlich.

APIs benötigen außerdem geeignete Authentifizierung.

Beispiele:

API-Key

OAuth

Access Tokens

Geheime Zugangsdaten gehören dabei nicht in:

Prompts,

öffentlichen Code,

Logs.

Sie gehören in eine kontrollierte Secret-Verwaltung.

Für große Datenmengen kommen weitere Konzepte hinzu:

Pagination

Rate Limiting

Queues

Retries

Idempotenz

Timeouts

Gerade Idempotenz ist für kritische Aktionen wichtig.

Wenn ein API-Request wegen eines Netzwerkfehlers wiederholt wird, darf eine Zahlung beispielsweise nicht versehentlich zweimal ausgeführt werden.

APIs können zusätzlich versioniert werden.

/v1/
↓
/v2/

Damit lassen sich Schnittstellen weiterentwickeln, ohne bestehende Integrationen sofort zu zerstören.

Und APIs sind nicht auf fremde Cloud-Dienste beschränkt.

Auch:

WordPress,

lokale KI-Server,

eigene Datenbanken,

interne Microservices

können definierte APIs bereitstellen.

Dadurch lässt sich eine sehr flexible Architektur aufbauen:

Automatisierung
│
├── WordPress API
├── CRM API
├── Daten-API
├── lokale KI API
└── externe Dienste

Der Workflow muss nicht wissen, wie diese Systeme intern funktionieren.

Er braucht lediglich den veröffentlichten Schnittstellenvertrag.

Für KI ist das besonders wichtig.

Ein Sprachmodell sollte operative Fakten nicht erfinden.

Statt:

LLM:
"Der Kunde hat vermutlich drei offene Rechnungen."

besser:

LLM
↓
get_open_invoices
↓
API
↓
3
↓
LLM formuliert

Damit entsteht eine klare Aufgabenteilung:

API
→ liefert tatsächlichen Systemzustand

LLM
→ versteht und formuliert

Workflow
→ orchestriert

Softwarelogik
→ validiert und entscheidet

Mensch
→ kontrolliert kritische Fälle

Und genau dadurch wird eine API zu weit mehr als nur einem technischen Entwicklerbegriff.

Sie ist eine der zentralen Grundlagen dafür, dass moderne Softwaresysteme, Automatisierungen und KI-Komponenten überhaupt zuverlässig miteinander arbeiten können.