Was ist eine API? Einfach erklärt, mit echten Beispielen (2026)

Das Wort taucht überall auf: Die Wetter-App „holt die Daten über eine API“, der Onlineshop „hat eine API zum Warenwirtschaftssystem“, und jedes KI-Tool verkauft dir einen „API-Key“. Wer nicht programmiert, nickt meistens und hofft, dass niemand nachfragt.

Was ist eine API? Eine API (Application Programming Interface, auf Deutsch Programmierschnittstelle) ist eine festgelegte Art, wie ein Programm ein anderes Programm um etwas bitten darf — und wie die Antwort aussieht. Sie ist ein Vertrag: „Wenn du mich so fragst, antworte ich dir so.“ Menschen benutzen eine Oberfläche mit Knöpfen; Programme benutzen eine API.

In diesem Artikel erklären wir das von Grund auf: was bei einem API-Aufruf tatsächlich über die Leitung geht, was Endpunkte, Methoden und Statuscodes sind, wofür ein API-Key gut ist und warum er geheim bleiben muss, wie Rate Limits funktionieren — und warum eine Website, die überhaupt keine API hat, trotzdem jeden Tag Hunderte Anfragen an /api/ bekommt. Alle Zahlen stammen aus Messungen auf unserem eigenen Server am 12. Oktober 2026, nicht aus Dokumentationen.

Das Video von „Programmieren Starten“ ist von 2018 — die Grundidee hat sich seitdem nicht verändert, und es ist eine der wenigen deutschsprachigen Einführungen, die ohne Fachjargon auskommen. Weiter unten folgt eine aktuelle englische Erklärung von AWS.

Was ist eine API — die kurze Antwort in fünf Sätzen

1. Eine API ist eine Schnittstelle zwischen zwei Programmen, nicht zwischen Mensch und Programm.
2. Sie legt fest, welche Fragen erlaubt sind und in welchem Format die Antwort kommt.
3. Im Web läuft das fast immer über HTTP — dasselbe Protokoll, über das dein Browser diese Seite geladen hat.
4. Die Antwort ist meistens JSON, ein schlichtes Textformat für strukturierte Daten.
5. Wer die API anbietet, behält die Kontrolle: Er entscheidet, wer fragen darf, wie oft und was er zu sehen bekommt.

Der wichtigste Gedanke steckt in Punkt 5. Eine API ist nicht einfach „Zugriff auf die Datenbank“. Sie ist im Gegenteil eine Tür mit Türsteher: Die Datenbank selbst bleibt verborgen, und nach außen gibt es nur genau die Fragen, die der Betreiber beantworten will.

Die Restaurant-Analogie — und wo sie hinkt

Die bekannteste Erklärung geht so: Du sitzt im Restaurant (das bist du, das aufrufende Programm). Die Küche (der Server mit den Daten) ist für dich nicht zugänglich. Der Kellner ist die API: Er nimmt deine Bestellung in einer festgelegten Form entgegen — nämlich von der Speisekarte —, bringt sie in die Küche und kommt mit dem Ergebnis zurück.

Das trifft drei Dinge gut:

• Die Speisekarte ist die Dokumentation. Was nicht draufsteht, kannst du nicht bestellen, egal wie höflich du fragst.
• Du musst nicht wissen, wie die Küche arbeitet. Ob dort ein Gasherd oder ein Induktionsfeld steht, ist dir egal. Bei einer API ist es dir genauso egal, ob dahinter PostgreSQL, eine Excel-Datei oder ein anderer Dienst steckt.
• Die Küche kann umgebaut werden, ohne dass sich für dich etwas ändert — solange die Speisekarte gleich bleibt.

Wo die Analogie hinkt: Ein Kellner merkt sich, wer du bist. Die meisten Web-APIs tun das nicht. Jede Anfrage steht für sich allein und muss alles mitbringen, was der Server wissen muss — auch den Nachweis, wer du bist. Das nennt man zustandslos (stateless), und es ist der Grund, warum dein API-Key bei jeder einzelnen Anfrage mitgeschickt wird und nicht nur einmal beim „Anmelden“.

Was bei einem API-Aufruf wirklich passiert

Genug Bilder. So sieht ein echter Aufruf aus. Wir fragen den kostenlosen Wetterdienst Open-Meteo nach der aktuellen Temperatur im Sauerland:

curl "https://api.open-meteo.com/v1/forecast?latitude=51.37&longitude=8.38&current=temperature_2m"

Die Antwort, die unser Server am 12.10.2026 um 07:00 UTC bekommen hat (gekürzt):

{
  "latitude": 51.37532,
  "longitude": 8.400086,
  "generationtime_ms": 5.78,
  "elevation": 440.0,
  "current_units": { "temperature_2m": "°C" },
  "current": { "time": "2026-10-12T07:00", "temperature_2m": 4.5 }
}

4,5 Grad. Mehr ist da nicht passiert — und genau das ist der Punkt. Kein Login, keine Oberfläche, keine Werbung. Ein Programm schickt eine Zeile Text, ein anderes Programm antwortet mit ein paar Zeilen Text, die sich direkt weiterverarbeiten lassen.

Zerlegt sieht die Anfrage so aus:

Wie lange so ein Aufruf dauert — gemessen

Wir haben den Aufruf von unserem Server in Deutschland aus gemessen. Bei den ersten fünf Aufrufen zerlegt curl die Zeit so:

Ein zweiter Durchgang mit 20 Aufrufen direkt danach lag bei 24 ms im Median (95 % unter 29 ms). Warum die ersten Aufrufe dreimal so lange brauchten, können wir von außen nicht sehen — vermutlich lag die Antwort beim zweiten Mal schon in einem Cache des Anbieters. Der Server selbst meldet im Feld generationtime_ms knapp 6 ms Rechenzeit.

Zum Vergleich: Dieselbe Art Anfrage an eine winzige API auf demselben Rechner (dazu gleich mehr) dauerte 0,5 ms im Median, bei 200 Wiederholungen. Der Unterschied zwischen 0,5 und 24 ms ist fast vollständig Netzwerk: Entfernung, Verschlüsselung, Verbindungsaufbau. Das ist die erste praktische Lehre über APIs: Ein externer API-Aufruf ist ungefähr fünfzigmal langsamer als ein lokaler Funktionsaufruf — mindestens. Wer in einer Schleife über 1.000 Produkte jeweils eine API fragt, wartet nicht 0,5 Sekunden, sondern eher 25 bis 80.

Die Bausteine einer Web-API

Fast alle APIs, denen du im Web begegnest, folgen dem Stil REST (Representational State Transfer). Das ist kein Standard mit Prüfsiegel, sondern eine Sammlung von Konventionen. Wer sie einmal verstanden hat, kann die meisten APIs lesen, ohne die Dokumentation komplett durchzuarbeiten.

Endpunkte: die Adressen

Ein Endpunkt ist eine URL, hinter der eine bestimmte Sache steckt. Bei einer REST-API sind das typischerweise Dinge (Substantive), keine Tätigkeiten:

/todos          → alle Aufgaben
/todos/42       → die Aufgabe mit der Nummer 42
/users/7/orders → die Bestellungen von Nutzer 7

Methoden: was du mit der Adresse machen willst

Was mit dem Ding geschehen soll, sagt die HTTP-Methode:

Die Faustregel: GET darf nie etwas verändern. Ein Link, ein Vorschaubild in einem Messenger oder ein Suchmaschinen-Crawler ruft GET-Adressen auf, ohne zu fragen. Wer „Löschen“ über einen GET-Link baut, hat die Daten irgendwann gelöscht, weil ein Bot vorbeikam.

Statuscodes: wie es gelaufen ist

Jede Antwort hat eine dreistellige Zahl, die sagt, ob es geklappt hat. Die wichtigsten, die du in der Praxis siehst:

Die Regel ist bequem zu merken: 4xx heißt, an deiner Anfrage stimmt etwas nicht. 5xx heißt, am Server stimmt etwas nicht. Bei einem 4xx-Fehler hilft es nichts, dieselbe Anfrage noch einmal zu schicken. Bei 5xx und bei 429 schon — nur bitte mit Pause.

Header und Body: Umschlag und Inhalt

Eine Anfrage besteht aus zwei Teilen. Die Header sind wie die Angaben auf einem Briefumschlag: wer du bist (Authorization), welches Format du schickst (Content-Type: application/json), welches du zurückhaben willst (Accept). Der Body ist der eigentliche Inhalt — bei GET meist leer, bei POST zum Beispiel die neue Aufgabe als JSON. Wer JSON noch nicht kennt: Unser Artikel Was ist eine JSON-Datei erklärt das Format und seine Fallen von Grund auf.

Eine eigene API in 16 Zeilen

Am schnellsten versteht man eine API, wenn man eine baut. Das folgende Programm ist eine vollständige, funktionierende Web-API in Node.js — ohne Framework, ohne Bibliothek, 16 Zeilen:

import http from 'node:http';
const todos = [{ id: 1, text: 'Artikel schreiben', done: false }];
http.createServer((req, res) => {
  const send = (code, body) => { res.writeHead(code, { 'Content-Type': 'application/json' }); res.end(JSON.stringify(body)); };
  if (req.url === '/todos' && req.method === 'GET') return send(200, todos);
  if (req.url === '/todos' && req.method === 'POST') {
    let raw = ''; req.on('data', c => raw += c);
    req.on('end', () => {
      try { const { text } = JSON.parse(raw);
        if (typeof text !== 'string' || !text) return send(422, { error: 'text fehlt' });
        const todo = { id: todos.length + 1, text, done: false }; todos.push(todo); send(201, todo);
      } catch { send(400, { error: 'kein gültiges JSON' }); }
    }); return;
  }
  send(404, { error: 'nicht gefunden' });
}).listen(3999, '127.0.0.1');

Und so hat sie auf unserem Server geantwortet:

$ curl localhost:3999/todos
[{"id":1,"text":"Artikel schreiben","done":false}]          [200]

$ curl -X POST localhost:3999/todos -d '{"text":"Kaffee"}'
{"id":2,"text":"Kaffee","done":false}                       [201]

$ curl -X POST localhost:3999/todos -d '{"text":}'
{"error":"kein gültiges JSON"}                              [400]

$ curl -X POST localhost:3999/todos -d '{}'
{"error":"text fehlt"}                                      [422]

$ curl localhost:3999/nix
{"error":"nicht gefunden"}                                  [404]

Fünf Aufrufe, fünf verschiedene Statuscodes, und jeder sagt dem Aufrufer genau, was los ist. Das ist die eigentliche Arbeit beim Bauen einer API: nicht der glückliche Fall, sondern die Antworten auf alles, was schiefgehen kann. Der Unterschied zwischen 400 und 422 wirkt pedantisch, ist für den Aufrufer aber Gold wert: Bei 400 hat sein JSON einen Syntaxfehler, bei 422 fehlt ein Feld. Das sind zwei völlig verschiedene Bugs.

Was diesem Mini-Beispiel fehlt, ist genau das, was eine echte API ausmacht: Die Daten sind nach einem Neustart weg (keine Datenbank — dazu passt unser Vergleich SQLite vs. PostgreSQL), jeder darf schreiben (keine Authentifizierung), und niemand bremst einen Aufrufer, der 10.000 Anfragen pro Sekunde schickt (kein Rate Limit). Diesen drei Themen widmen sich die nächsten Abschnitte.

Englisch, von AWS Developers, aus dem September 2026: erklärt besonders gut, warum Firmen ihre Logik überhaupt hinter einer API verstecken, statt sie in Website und App doppelt zu bauen.

API-Keys, Tokens und Authentifizierung

Die meisten APIs wollen wissen, wer fragt. Nicht aus Neugier, sondern aus drei handfesten Gründen: um abzurechnen, um Missbrauch einer bestimmten Person zuordnen zu können und um zu entscheiden, was derjenige sehen darf.

API-Key: der einfachste Weg

Ein API-Key ist eine lange, zufällige Zeichenkette, die dir der Anbieter gibt. Du schickst sie bei jeder Anfrage mit, meistens im Header:

curl -H "Authorization: Bearer DEIN_KEY" https://api.beispiel.de/v1/daten

Was passiert, wenn der Key falsch ist, haben wir bei GitHub ausprobiert:

$ curl -H "Authorization: Bearer falsch" https://api.github.com/user
{ "message": "Bad credentials", "status": "401" }

Und was passiert, wenn man ohne jeden Key etwas versucht, das Rechte braucht — etwa eines unserer eigenen öffentlichen Repositories zu löschen oder dort ein Issue anzulegen? Beide Male 401, nicht 403 und nicht 404. GitHub sagt damit: „Ich weiß nicht, wer du bist, also prüfe ich gar nicht erst, ob du darfst.“ Lesen dagegen geht ohne Key: GET auf dasselbe Repository lieferte 200 mit 8.037 Bytes JSON.

Der Key ist ein Passwort — behandle ihn auch so

Das ist der Teil, an dem in der Praxis am meisten schiefgeht. Ein API-Key ist ein Passwort, das nicht nach einem Passwort aussieht. Wer ihn hat, ist für die API du — inklusive deiner Rechnung. Typische Wege, wie Keys verloren gehen:

• Im Frontend-Code. Alles, was im Browser läuft, kann jeder Besucher lesen. Ein Key in einer JavaScript-Datei ist öffentlich, egal wie gut versteckt.
• Im Git-Repository. Einmal committet, steht der Key in der Historie, auch wenn er im nächsten Commit gelöscht wird.
• In einer .env-Datei, die der Webserver ausliefert. Dazu gleich echte Zahlen aus unserem Log.
• In Screenshots und Support-Tickets.

Die Regel: Keys gehören auf den Server, in Umgebungsvariablen oder einen Secret-Speicher, mit so wenigen Rechten wie möglich. Und wenn einer verloren geht: sofort beim Anbieter widerrufen, nicht nur aus dem Code löschen. Ein gelöschter Key ist nicht ungültig — er ist nur nicht mehr bei dir.

OAuth: wenn du jemand anderem Zugriff gibst

Wenn eine App „mit Google anmelden“ anbietet oder ein Tool Zugriff auf dein GitHub-Konto möchte, steckt meistens OAuth 2.0 dahinter. Der Unterschied zum API-Key: Du gibst der App nicht dein Passwort, sondern sie bekommt vom Anbieter ein zeitlich begrenztes Token mit eingeschränkten Rechten („darf Repositories lesen, nicht löschen“). Das kannst du jederzeit zurückziehen, ohne dein Passwort zu ändern. Für eigene Skripte reicht in aller Regel ein API-Key; OAuth wird relevant, sobald fremde Nutzer deiner App Zugriff auf ihre Konten geben.

Rate Limits: warum eine API „Stopp“ sagt

Jede ernstzunehmende öffentliche API begrenzt, wie oft du fragen darfst. Bei GitHub sieht man das direkt in den Antwort-Headern:

x-ratelimit-limit: 60
x-ratelimit-remaining: 59
x-ratelimit-used: 1
x-ratelimit-reset: 1791792137

Ohne Anmeldung: 60 Anfragen pro Stunde, gezählt pro IP-Adresse. Mit unserem Token stand dort "limit": 5000. Der reset-Wert ist ein Unix-Zeitstempel — der Moment, an dem das Kontingent wieder voll ist. Wer das Limit reißt, bekommt keinen Absturz, sondern einen sauberen 403- oder 429-Statuscode mit genau diesen Headern, und ein gut gebautes Programm wartet dann bis zum Reset, statt stumpf weiterzufragen.

Der Trick, der Kontingent spart — und wo er nicht wirkt

Viele APIs schicken mit jeder Antwort einen ETag mit, eine Art Fingerabdruck des Inhalts. Fragst du beim nächsten Mal mit If-None-Match: <ETag> nach und hat sich nichts geändert, antwortet der Server mit 304 Not Modified und ohne Body. Das spart Bandbreite — und laut GitHub-Dokumentation auch das Kontingent.

Wir haben das nachgemessen, und das Ergebnis ist interessanter als die Dokumentation:

Ohne Anmeldung kostete jede 304-Antwort trotzdem eine Anfrage vom Kontingent. Mit Token kostete sie nichts. Der Spartrick funktioniert bei GitHub also nur für angemeldete Aufrufe — wer anonym pollt, verbraucht seine 60 Anfragen auch dann, wenn sich nichts geändert hat. Das ist genau die Art Detail, die in keinem Einsteiger-Tutorial steht und an der ein Skript dann nachts um drei mit „rate limit exceeded“ aussteigt.

Weitere Header, die dir Arbeit abnehmen

• Kompression: Dieselbe GitHub-Antwort war unkomprimiert 8.037 Bytes groß, mit Accept-Encoding: gzip nur noch 1.638 Bytes — ein Fünftel. Die meisten HTTP-Bibliotheken machen das automatisch, curl nur auf Nachfrage.
• Paginierung: Listen kommen fast nie komplett. Bei GitHub steht im Link-Header, wo es weitergeht: Unsere Anfrage nach den Repositories unserer Organisation mit per_page=2 lieferte rel="next" (Seite 2) und rel="last" (Seite 6). Wer nur die erste Antwort liest, glaubt, es gäbe zwei Repositories.
• CORS: Ob eine API direkt aus dem Browser aufgerufen werden darf, entscheidet der Header Access-Control-Allow-Origin. Bei Open-Meteo, GitHub und Moltbook stand dort * — jeder darf. Bei APIs, die das nicht erlauben, ist der Aufruf aus dem Browser blockiert, obwohl er per curl funktioniert. Das ist kein Fehler der API, sondern eine Schutzfunktion des Browsers.

Welche Arten von APIs es gibt

„API“ ist ein Oberbegriff. Im Alltag begegnen dir vor allem diese:

Web-APIs (REST)

Das, worum es in diesem Artikel hauptsächlich geht: HTTP-Anfragen, JSON-Antworten, Endpunkte als URLs. Die meisten öffentlichen Dienste — Zahlungsanbieter, Versanddienstleister, Wetterdienste, KI-Modelle — bieten REST-APIs an.

GraphQL

Bei GraphQL gibt es nur einen Endpunkt, und der Aufrufer beschreibt in einer Abfragesprache genau, welche Felder er haben will. Vorteil: keine überflüssigen Daten, keine zehn Anfragen für zehn zusammenhängende Dinge. Nachteil: Caching und Rate Limiting sind schwieriger, weil jede Anfrage anders aussieht. Den direkten Vergleich mit REST schauen wir uns in einem eigenen Artikel an.

Webhooks: die umgedrehte API

Bei einer normalen API fragst du. Bei einem Webhook meldet sich der andere Dienst bei dir, sobald etwas passiert — zum Beispiel ruft der Zahlungsanbieter deine Adresse auf, wenn eine Zahlung eingegangen ist. Das erspart dir, alle paar Sekunden nachzufragen („ist schon bezahlt?“), und macht dich unabhängig von Rate Limits. Dafür musst du einen Endpunkt betreiben, der von außen erreichbar ist — und prüfen, dass die Anfrage wirklich vom Anbieter kommt, meist über eine Signatur im Header.

Bibliotheks- und System-APIs

Nicht jede API läuft übers Netz. Wenn ein Programm eine Datei öffnet, ruft es die API des Betriebssystems auf. Wenn du in JavaScript JSON.parse() schreibst, benutzt du die API der Sprache. Das Prinzip ist dasselbe — ein Vertrag, wie man etwas aufruft und was zurückkommt —, nur ohne HTTP dazwischen.

Private, Partner- und öffentliche APIs

Unterschieden wird auch danach, wer die API benutzen darf. Private APIs verbinden die eigene Website mit dem eigenen Backend; Partner-APIs bekommen ausgewählte Geschäftspartner (etwa ein Marktplatz für Händler); öffentliche APIs kann jeder nach Registrierung nutzen. Technisch sind sie oft identisch — der Unterschied liegt in Dokumentation, Verträgen und darin, wie lange eine alte Version weiterlaufen muss.

Wofür APIs im Alltag gebraucht werden

Fast jede App, die du benutzt, ist im Kern eine Oberfläche vor ein paar APIs:

• Wetter-Apps fragen eine Wetter-API, wie oben gezeigt.
• Onlineshops sprechen über APIs mit Zahlungsanbietern, Versanddienstleistern, Warenwirtschaft und Marktplätzen. Ein Shopsystem wie Shopware hat selbst eine vollständige API, über die sich Produkte, Bestellungen und Kunden verwalten lassen — Grundlage jeder Anbindung, siehe unsere Shopware-Installation.
• „Mit Google anmelden“ ist OAuth über die API von Google.
• KI-Tools sind fast immer API-Aufrufe: Die App schickt deinen Text an die API eines Modellanbieters und zeigt die Antwort an. Wenn ein Tool einen „API-Key“ von dir will, will es auf deine Rechnung bei diesem Anbieter rechnen. Mehr dazu in ChatGPT vs. Claude vs. Gemini und, für KI-Agenten, die selbstständig APIs aufrufen, in unserem Überblick zu KI-Agenten für Unternehmen.
• Automatisierung mit Tools wie Zapier, n8n oder einem einfachen Cronjob ist nichts anderes als „rufe API A auf, nimm das Ergebnis, schicke es an API B“. Wie so ein regelmäßiger Aufruf auf einem eigenen Server läuft, zeigt unser Artikel Cronjob erstellen.

Warum Bots ständig nach APIs suchen, die es nicht gibt

Jetzt zum Teil, den man in keiner Einführung findet. getmind.io ist eine statische Website: HTML-Dateien, Bilder, sonst nichts. Es gibt hier keine einzige API. Trotzdem haben wir in unseren Server-Logs nachgezählt.

Zeitraum 7. September bis 12. Oktober 2026, 197.887 Anfragen insgesamt. Davon gingen 10.179 an Pfade wie /api/…, /graphql, /v1/graphql oder /wp-json — von 525 verschiedenen IP-Adressen. Ergebnis: 9.964-mal 404, 215-mal eine Weiterleitung, kein einziger Treffer. Die häufigsten Ziele:

Und gleich daneben, nicht API, aber dasselbe Motiv: 578-mal /.env, 395-mal /.env.local, 316-mal /.env.production. Das sind die Dateien, in denen viele Projekte ihre API-Keys aufbewahren. Die Scanner suchen also nicht nach der API selbst, sondern nach den Schlüsseln zu fremden APIs — Zahlungsdienste, Cloud-Konten, KI-Anbieter.

Daraus folgen drei sehr praktische Regeln, wenn du selbst eine API betreibst:

1. Rechne damit, dass sie gefunden wird. Ein Endpunkt, „den niemand kennt“, wird innerhalb von Tagen von automatisierten Scannern abgeklopft. Unbekanntheit ist kein Schutz.
2. Konfigurationsdateien gehören nicht ins Web-Verzeichnis. Wenn /.env auf deinem Server 200 statt 404 liefert, sind deine Keys öffentlich.
3. Antworte auf Unbekanntes knapp. Eine 404 ohne Details verrät nichts. Eine Fehlerseite mit Framework-Version, Stacktrace und Datenbankname verrät alles. Wie man solche Dauerbesucher zusätzlich aussperrt, zeigen Fail2ban einrichten und IT-Sicherheitslücken.

Wer eine eigene API ins Netz stellt, setzt sie übrigens fast immer hinter einen Reverse Proxy, der HTTPS, Kompression und erste Filter übernimmt, bevor eine Anfrage das eigentliche Programm erreicht.

Woran du eine gute API erkennst

Wenn du eine API auswählen musst — für einen Shop, ein Skript, ein Projekt —, sind das die Punkte, die wir prüfen, bevor wir eine Zeile Code schreiben:

• Dokumentation mit echten Beispielen, inklusive der Fehlerfälle. Eine Doku, die nur den glücklichen Fall zeigt, verschweigt die Hälfte.
• Versionierung in der URL oder im Header (/v1/, /v2/). Ohne Versionsnummer kann der Anbieter dir jederzeit die Antwortstruktur unter den Füßen wegziehen.
• Sinnvolle Statuscodes. Eine API, die bei Fehlern 200 OK mit {"error": true} im Body schickt, macht jede Fehlerbehandlung mühsam.
• Dokumentierte Rate Limits — und Header, die den aktuellen Stand verraten.
• Eine Testumgebung (Sandbox), besonders bei allem, was Geld bewegt.
• Eine Statusseite und ein Changelog. Wenn du nachts wissen willst, ob der Fehler bei dir oder beim Anbieter liegt, ist das die erste Adresse.
• Ein Weg, Keys mit eingeschränkten Rechten zu erzeugen. Ein Skript, das nur Bestellungen liest, braucht keinen Key, der Produkte löschen kann.

Häufige Fragen zur API

Was ist eine API einfach erklärt?

Eine API ist eine festgelegte Schnittstelle, über die ein Programm ein anderes Programm um Daten oder eine Aktion bitten kann. Man kann sie sich wie eine Speisekarte mit Kellner vorstellen: Du darfst nur bestellen, was auf der Karte steht, bekommst es in einer festen Form zurück und musst nicht wissen, wie die Küche dahinter arbeitet. Im Web läuft das meist über HTTP mit JSON-Antworten.

Wofür steht die Abkürzung API?

API steht für Application Programming Interface, auf Deutsch Programmierschnittstelle oder Anwendungsprogrammierschnittstelle. Gemeint ist eine Schnittstelle für Programme, nicht für Menschen — im Gegensatz zur Benutzeroberfläche (User Interface), die für Menschen gemacht ist.

Was ist der Unterschied zwischen API und Schnittstelle?

Im Deutschen werden beide Begriffe oft gleichbedeutend verwendet. „Schnittstelle“ ist allgemeiner und kann auch Hardware meinen, etwa einen USB-Anschluss. Eine API ist speziell eine Software-Schnittstelle: ein festgelegter Satz von Aufrufen, über die Programme miteinander sprechen.

Was ist ein API-Key und wie bekomme ich einen?

Ein API-Key ist eine lange, zufällige Zeichenkette, mit der du dich bei einer API ausweist. Du bekommst ihn nach der Registrierung im Entwickler- oder Kontobereich des Anbieters. Er wird bei jeder Anfrage mitgeschickt, meist im Authorization-Header, und muss geheim bleiben wie ein Passwort — wer ihn hat, handelt in deinem Namen und auf deine Rechnung.

Ist eine API kostenlos?

Das entscheidet der Anbieter. Viele APIs haben ein kostenloses Kontingent: Open-Meteo beantwortet einfache Anfragen ohne Anmeldung, GitHub erlaubt anonym 60 Anfragen pro Stunde und mit Token 5.000. KI-Modelle, Zahlungsabwicklung oder Karten-APIs rechnen dagegen meist pro Anfrage oder pro verarbeiteter Datenmenge ab.

Was ist der Unterschied zwischen REST-API und API?

„API“ ist der Oberbegriff für jede Programmierschnittstelle. Eine REST-API ist eine bestimmte Bauart von Web-API, die HTTP-Methoden (GET, POST, PUT, DELETE), Ressourcen als URLs und meist JSON verwendet. Andere Bauarten sind etwa GraphQL, gRPC oder ältere SOAP-Schnittstellen.

Brauche ich Programmierkenntnisse, um eine API zu nutzen?

Für einen ersten Aufruf nicht: Viele GET-Anfragen lassen sich direkt im Browser öffnen, und mit curl reicht eine Zeile im Terminal. Automatisierungstools wie Zapier oder n8n machen API-Aufrufe per Klick. Sobald du Daten verarbeiten, Fehler behandeln oder regelmäßig abfragen willst, sind Grundkenntnisse in einer Sprache wie Python oder JavaScript aber sehr hilfreich.

Was bedeutet der Fehler 401 bei einer API?

401 heißt, dass die API nicht weiß, wer du bist: Der Key fehlt, ist falsch geschrieben, abgelaufen oder steht im falschen Header. Bei GitHub lautet die Meldung dann „Bad credentials“. Im Unterschied dazu bedeutet 403, dass du zwar erkannt wurdest, aber keine Berechtigung für diese Aktion hast.

Was bedeutet der Fehler 429?

429 Too Many Requests heißt, dass du das Rate Limit überschritten hast. Die Lösung ist warten, nicht wiederholen: Oft steht im Header Retry-After oder einem ratelimit-reset-Feld, ab wann wieder Anfragen erlaubt sind. Gute Programme warten automatisch mit wachsenden Abständen (Exponential Backoff).

Ist eine API sicher?

Eine API ist so sicher wie ihre Absicherung. Typische Schwachstellen sind fehlende Berechtigungsprüfungen (Nutzer A kann über /orders/124 die Bestellung von Nutzer B lesen), geleakte Keys, fehlende Rate Limits und zu ausführliche Fehlermeldungen. In unserem eigenen Log kamen in fünf Wochen über 10.000 automatisierte Anfragen an API-Pfade — eine API im Netz wird gefunden, egal ob sie verlinkt ist.

Was ist der Unterschied zwischen API und Webhook?

Bei einer API fragst du aktiv nach („Gibt es neue Bestellungen?“). Bei einem Webhook meldet sich der andere Dienst von selbst bei dir, sobald etwas passiert („Hier ist eine neue Bestellung“). Webhooks sparen ständiges Nachfragen, setzen aber voraus, dass du einen von außen erreichbaren Endpunkt betreibst und die Herkunft der Meldung prüfst.

Fazit

Eine API ist im Kern nichts Geheimnisvolles: ein Vertrag zwischen zwei Programmen, meistens als HTTP-Anfrage mit JSON-Antwort. Den ersten Aufruf schreibst du in einer Zeile, und eine funktionierende eigene API passt in 16 Zeilen.

Der Aufwand steckt woanders — und unsere Messungen zeigen ziemlich genau, wo. Ein externer Aufruf ist rund fünfzigmal langsamer als ein lokaler, und wer das in einer Schleife ignoriert, wartet Minuten statt Sekunden. Ein Spartrick, den die Dokumentation verspricht, wirkt bei GitHub nur mit Anmeldung; anonym kostet auch die „hat sich nicht geändert“-Antwort ein Stück Kontingent. Eine Liste, deren erste Seite zwei Einträge zeigt, hat in Wahrheit sechs Seiten. Und eine Website ganz ohne API bekommt trotzdem jeden Tag Hunderte Anfragen an /api/ und /.env, weil irgendwo da draußen jemand hofft, dass du deine Schlüssel liegen gelassen hast.

Eine API zu benutzen ist leicht. Sie gut zu benutzen heißt: die Fehlerfälle lesen, nicht nur die Beispiele.

Wenn du weitermachen willst: Was ist eine JSON-Datei erklärt das Format, in dem fast jede API antwortet, Was ist ein Reverse Proxy zeigt, wie eine eigene API sauber ins Netz kommt, und Was ist Docker erklärt, wie man sie so verpackt, dass sie überall gleich läuft. Wer gleich einen eigenen Server dafür aufsetzt, startet mit Linux-Server einrichten.