API einfach erklärt: So verbinden sich Anwendungen

Das Entscheidende ist der Vertrag dahinter: Welche Adresse darf aufgerufen werden? Welche Daten sind erlaubt? Wer darf was tun? Wie sehen Erfolg und Fehler aus?

Die kurze Antwort: Eine API ist sinnvoll, wenn Daten oder Aktionen regelmäßig, automatisch und kontrolliert zwischen Systemen fließen sollen. Für einen einmaligen Datenumzug reicht oft ein Export. Für einen einfachen Standardprozess kann eine fertige Integration besser sein.

Was ist eine API?

API steht für „Application Programming Interface“, auf Deutsch „Programmierschnittstelle“. Sie beschreibt Regeln, mit denen ein Programm Funktionen oder Daten eines anderen Programms nutzt, ohne dessen inneren Code zu kennen.

Der Restaurantvergleich erklärt Anfrage und Antwort, verschweigt aber Rechte, Fehler und Änderungen. Präziser ist ein beschrifteter Serviceschalter:

• Der Endpunkt ist der richtige Schalter.
• Die Methode sagt, was du tun willst.
• Die Daten enthalten die nötigen Angaben.
• Ein Token oder API-Schlüssel weist die Anwendung aus.
• Die Antwort enthält Ergebnis und Status.
• Die Dokumentation ist die Bedienungsanleitung.

Eine API übersetzt also nicht beliebige Wünsche. Sie akzeptiert nur, was ihr Vertrag vorsieht.

So verbinden sich zwei Anwendungen – Schritt für Schritt

Nehmen wir einen Onlineshop, der nach einer Bestellung automatisch einen Versandauftrag anlegt.

1. Der Shop erkennt ein Ereignis. Eine Bestellung wurde bezahlt.
2. Er wählt den Endpunkt. Zum Beispiel die Adresse für neue Sendungen.
3. Er sendet eine Anfrage. Sie enthält POST, einen Berechtigungsnachweis und die Versanddaten.
4. Der Versanddienst prüft. Sind Token, Felder, Rechte und Limit gültig?
5. Der Dienst führt die Aktion aus. Er legt eine Sendung an.
6. Er antwortet. Etwa mit Sendungsnummer und Status 201 für „erstellt“ oder mit Fehlercode und Fehlermeldung.

Dieser Ablauf heißt häufig Request und Response. Viele Web-APIs nutzen HTTP, also dasselbe Grundprotokoll wie Websites. API ist jedoch der Oberbegriff; nicht jede API ist eine REST-API und nicht jede Schnittstelle arbeitet nur mit HTTP und JSON.

Ein vereinfachter API-Aufruf

Der Ausschnitt zeigt Adresse, Methode, Berechtigung und Nutzdaten. Echte Feldnamen und Regeln stehen immer in der Dokumentation des Anbieters.

POST https://api.versand-beispiel.de/v1/sendungen
Authorization: Bearer TOKEN_PLACEHOLDER
Content-Type: application/json

{
  "bestellnummer": "B-1042",
  "land": "DE"
}

HTTP/1.1 201 Created
{
  "sendungsnummer": "S-9081",
  "status": "angelegt"
}

Die wichtigsten Bausteine ohne Fachnebel

Endpunkt

Ein Endpunkt ist eine konkrete Adresse für eine Ressource oder Funktion, etwa /kunden oder /sendungen. Erst zusammen mit Methode, Parametern und Berechtigung wird daraus eine eindeutige Anfrage.

GET, POST, PUT, PATCH und DELETE

• GET liest Daten.
• POST übermittelt Daten und erzeugt häufig etwas Neues.
• PUT ersetzt eine Ressource vollständig.
• PATCH ändert ausgewählte Teile.
• DELETE fordert das Löschen einer Ressource an.

Das sind verbreitete Bedeutungen, keine Einladung zum Raten. Maßgeblich ist die API-Dokumentation. Die HTTP-Methoden bei MDN erklären auch Eigenschaften wie Idempotenz.

JSON und andere Datenformate

Viele Web-APIs senden strukturierte Daten als JSON, weil Menschen und Programme es gut lesen können. JSON ist aber keine Voraussetzung. Auch XML, Dateien, Binärdaten und andere Formate kommen vor.

Statuscodes und Fehlermeldungen

2xx steht für Erfolg, 4xx meist für ein Problem mit Anfrage, Berechtigung oder Ressource und 5xx für einen Serverfehler. Häufig sind 200 „OK“, 201 „Created“, 400 „Bad Request“, 401 „Unauthorized“ (nicht authentifiziert), 403 „Forbidden“, 404 „Not Found“, 429 „Too Many Requests“ und 500 „Internal Server Error“. Die HTTP-Statusübersicht von MDN erklärt sie genauer.

Ein gutes System speichert nicht nur „API kaputt“, sondern Statuscode, Zeitpunkt und eine sichere Anfrage-ID. Zugangsdaten und personenbezogene Inhalte gehören nicht ungefiltert ins Log.

Authentifizierung und Autorisierung

Authentifizierung beantwortet: Wer fragt an? Autorisierung: Was darf diese Identität tun?

Ein API-Schlüssel kann eine Anwendung identifizieren. OAuth eignet sich häufig, wenn ein Nutzer einem fremden Dienst begrenzten Zugriff geben soll, ohne sein Passwort weiterzugeben. OAuth ist ein Framework mit mehreren Abläufen. Für die Umsetzung ist die aktuelle OAuth-2.0-Sicherheitsempfehlung RFC 9700 wichtiger als ein zufälliges Tutorial.

REST, GraphQL, SOAP und Webhooks

• REST ist ein Architekturstil. REST-orientierte Web-APIs arbeiten meist mit Ressourcen, HTTP-Methoden und Statuscodes.
• GraphQL ist Abfragesprache und Laufzeit für APIs. Der Client beschreibt benötigte Felder.
• SOAP ist ein Nachrichtenprotokoll mit XML und formalen Verträgen. Es findet sich weiter in älteren und regulierten Umgebungen.
• Webhook bedeutet Zustellung in Gegenrichtung: Bei einem Ereignis ruft ein System automatisch deine URL auf.
• OpenAPI beschreibt HTTP-APIs maschinenlesbar, etwa Pfade, Operationen, Parameter, Antworten und Sicherheitsverfahren. Es ist nicht dasselbe wie REST.

Für Einsteiger ist REST meist der verständlichste Startpunkt. Ich würde aber nie allein wegen eines Modeworts migrieren. Prozess, Datenmenge, vorhandene Systeme und Betriebskompetenz entscheiden.

Wann lohnt sich eine API?

Eine API passt gut, wenn Daten häufig oder nahezu sofort fließen, Vorgänge automatisch starten, mehrere Anwendungen dieselbe kontrollierte Funktion nutzen oder Zugriffe nachvollziehbar sein müssen. Typische Beispiele sind CRM-Kontakte aus Formularen, Bestellungen an Versanddienste, Rechnungen an Buchhaltungssysteme, Kalenderbuchungen und Dashboard-Daten.

Eine API löst keine schlechten Prozesse. Sind Feldbedeutungen unklar, Daten doppelt oder Zuständigkeiten offen, transportiert die Schnittstelle das Problem nur schneller.

Wann ist etwas Einfacheres besser?

Für einen einmaligen Import ist CSV oft vernünftiger. Für einen verbreiteten Standardablauf spart eine vom Anbieter gepflegte Integration Zeit. Eine Automatisierungsplattform verbindet kleine, überschaubare Abläufe ohne eigenes Backend. Individuelle API-Integration lohnt sich, wenn Regeln, Datenvolumen, Kontrolle oder Stabilität darüber hinausgehen.

Meine Empfehlung: API-Versprechen in 15 Minuten prüfen

„API vorhanden“ ist für eine Kaufentscheidung zu wenig. Ich würde vor Demo oder Vertrag diese acht Belege suchen:

1. Dokumentation: Sind Endpunkte, Felder und Beispiele konkret beschrieben?
2. Benötigte Funktionen: Kann die API genau die nötigen Daten lesen und Aktionen ausführen?
3. Schreibzugriff: Manche APIs lesen nur. Erstellen, Ändern und Löschen getrennt prüfen.
4. Rechte: Gibt es begrenzte Scopes, eigene Service-Konten und sichere Schlüsselrotation?
5. Limits und Pagination: Wie viele Anfragen sind erlaubt? Wie werden große Listen aufgeteilt?
6. Fehler und Wiederholungen: Gibt es klare Fehlercodes, Retry-Hinweise und Schutz vor Doppelbuchungen?
7. Versionen: Gibt es Changelog und angekündigte Übergangsfristen?
8. Test und Support: Kann das Team ohne echte Kundendaten testen? Wer hilft bei Störungen?

Vier konkrete Fragen an die Beteiligten

• An den Anbieter: Welche Endpunkte, Limits, Versionen und Supportwege gelten für unseren Tarif?
• An die IT: Wo liegen Zugangsdaten, Logs und Zuständigkeit, und wie testen wir Fehlerfälle?
• An Datenschutz oder Informationssicherheit: Welche personenbezogenen Daten fließen wohin, auf welcher Grundlage und wie werden sie gelöscht?
• An den Prozessverantwortlichen: Welcher Ablauf ist wirklich nötig, welches System führt und was passiert bei Ausfall?

Warnzeichen sind Screenshots statt Dokumentation, ein gemeinsamer Admin-Schlüssel, unbekannte Limits, keine Testumgebung und „das klappt bestimmt über die API“. Ein OpenAPI-Dokument ist ein starkes Signal für prüfbare Struktur, ersetzt aber weder gute Beispiele noch verlässlichen Betrieb.

Für konkrete Requests hilft API-Apps für kleine Teams: Welche bleibt einfach?. „Was ist SaaS?“ ordnet ein, was bei extern betriebener Software zusätzlich zählt.

Was eine zuverlässige Integration zusätzlich braucht

Timeouts, Retries und Idempotenz

Netzwerke fallen gelegentlich aus. Eine Anwendung sollte nicht unbegrenzt warten. Ein Retry darf aber keine Bestellung oder Zahlung doppelt auslösen.

Idempotenz bedeutet: Die wiederholte gleiche Anfrage erzeugt nicht mehrfach dieselbe Wirkung. Die HTTP-Methodenübersicht von MDN zeigt, dass einige Methoden von ihrer Semantik her idempotent sind. Stripe dokumentiert zusätzlich Idempotency Keys für sicher wiederholte POST-Anfragen. Das ist ein konkretes Anbieterbeispiel, keine Funktion jeder API.

Rate Limits und Pagination

Rate Limits begrenzen Anfragen oder gleichzeitige Zugriffe. Bei 429 sollte die Anwendung Anbieterhinweise beachten und später kontrolliert erneut versuchen. Große Listen kommen oft seitenweise. Wer nur die erste Seite verarbeitet, bemerkt Datenverlust womöglich lange nicht.

Monitoring und Verantwortung

Sichtbar sein sollten Erfolgsquote, Fehlerrate, Laufzeit, Wiederholungen und die letzte erfolgreiche Synchronisation. Ebenso wichtig ist eine klare Zuständigkeit.

Wie sicher ist eine API?

Eine API kann Zugriffe enger begrenzen als ein direkter Datenbankzugang. Sicher ist sie nicht automatisch. Die OWASP API Security Top 10 2023 nennt unter anderem fehlerhafte Berechtigungen, schwache Authentifizierung, unbeschränkten Ressourcenverbrauch, Fehlkonfiguration und unsicheren Umgang mit fremden APIs.

Für kleine Teams wichtig:

• Zugangsdaten nie in öffentliches Frontend, Chat oder Quellcode kopieren.
• Je Integration eigene, minimale Rechte vergeben.
• Secrets sicher speichern, wechseln und widerrufen.
• Eingaben und Antworten prüfen; fremde API-Daten sind nicht automatisch vertrauenswürdig.
• Personenbezogene Daten nur bei geklärtem Zweck, Vertrag, Speicherort und Löschweg übertragen.
• Test- und Produktionsdaten trennen.
• Nicht benötigte Endpunkte, Schlüssel und Versionen abschalten.

Häufige Fragen

Ist eine API dasselbe wie eine Datenbank?

Nein. Eine Datenbank speichert Daten. Eine API regelt, wie andere Software ausgewählte Daten oder Funktionen nutzen darf.

Brauche ich Programmierkenntnisse?

Zum Verstehen und Prüfen nicht zwingend. Für eine individuelle, zuverlässige Integration meist schon. No-Code-Tools lösen Datenmodell, Rechte, Fehlerbehandlung und Verantwortung nicht automatisch.

Ist REST dasselbe wie API?

Nein. API ist der Oberbegriff. REST ist ein möglicher Architekturstil für Web-APIs. GraphQL, SOAP, Bibliotheks- und Betriebssystem-Schnittstellen sind ebenfalls APIs.

Was kostet eine API?

Es gibt keinen allgemeinen Preis. API-Zugang kann enthalten sein, einen höheren Tarif oder nutzungsabhängige Gebühren verlangen. Prüfe auch Automatisierungsdienst, Entwicklung, Wartung und Fehlerbetrieb. Ohne aktuelle Preisseite und Vertrag wäre eine konkrete Zahl unseriös.

Woran erkenne ich gute API-Dokumentation?

Sie zeigt Authentifizierung, Endpunkte, Methoden, Pflichtfelder, Beispiele, Fehlercodes, Limits, Pagination, Versionen und Changelog. Eine OpenAPI Specification erleichtert Tests und Werkzeuge, garantiert allein aber keine gute Integration.

Fazit

Eine API ist ein verlässlicher Vertrag zwischen Software-Systemen: Anfrage hinein, kontrollierte Verarbeitung, eindeutige Antwort zurück. Für eine Unternehmensentscheidung zählen zusätzlich Rechte, Funktionen, Limits, Fehlerverhalten, Änderungen, Testbarkeit und Zuständigkeit.

Empfehlung: Prüfe nicht das Schlagwort „API“, sondern den konkreten Ablauf. Prüfe einen konkreten Geschäftsablauf vom Auslöser bis zum Fehlerfall. Zeigt der Anbieter Dokumentation, passende Rechte, nachvollziehbare Antworten und einen stabilen Änderungsweg, kann die Schnittstelle wirklich Arbeit abnehmen.