API (Schnittstelle)

Wie eine API funktioniert: Request und Response

Das Grundprinzip fast jeder API ist ein Frage-Antwort-Spiel. Ein System stellt eine Anfrage (Request) an ein anderes – etwa „Gib mir alle Bestellungen von heute“ oder „Lege diesen neuen Kunden an“. Das angesprochene System verarbeitet die Anfrage und schickt eine Antwort (Response) zurück, zum Beispiel die gewünschte Bestellliste oder eine Bestätigung, dass der Kunde gespeichert wurde. Dieser Ablauf wiederholt sich millionenfach im Hintergrund, ohne dass ein Anwender etwas davon bemerkt.

Damit beide Seiten sich verstehen, sind Aufbau und Format der Nachrichten genau vereinbart. Die Daten werden meist in einem maschinenlesbaren Format wie JSON übertragen – einer Struktur, die sowohl Programme leicht verarbeiten als auch Menschen halbwegs lesen können. Die API-Dokumentation des Anbieters beschreibt, welche Anfragen erlaubt sind, welche Felder mitgeschickt werden müssen und wie die Antwort aussieht. Für Nicht-Techniker genügt das Bild eines Kellners: Man bestellt nach der Speisekarte (der Dokumentation), die Küche (das System) bereitet zu, und man bekommt genau das zurück, was vereinbart war.

REST, Webhook und EDI: die wichtigsten Abgrenzungen

APIs unterscheiden sich in Stil und Übertragungsrichtung. Der heute mit Abstand verbreitetste Stil ist REST (siehe REST-API): eine schlanke, über das normale Web-Protokoll HTTP funktionierende Bauweise, bei der jede Ressource – Kunde, Auftrag, Artikel – über eine eigene Adresse (URL) ansprechbar ist. REST-APIs gelten als einfach zu verstehen, gut dokumentierbar und breit unterstützt, weshalb die meisten ERP-Systeme und Shops sie anbieten.

Ein wichtiger Gegenpol ist der Webhook. Bei einer klassischen API fragt das eigene System aktiv nach Daten (Pull) – es muss also wissen, wann es nachfragen soll. Ein Webhook dreht die Richtung um: Sobald im Quellsystem ein Ereignis eintritt, etwa eine neue Bestellung, schickt dieses von sich aus eine Nachricht (Push) an eine hinterlegte Adresse. Push spart ständiges Nachfragen und liefert Ereignisse nahezu in Echtzeit; in der Praxis kombinieren viele Integrationen beides.

Davon abzugrenzen ist EDI (Electronic Data Interchange). EDI ist der ältere, stark standardisierte Weg des Datenaustauschs zwischen Unternehmen – etwa für Bestellungen und Rechnungen im B2B-Handel mit großen Handelsketten. EDI folgt festen Nachrichtenstandards wie EDIFACT und ist oft Voraussetzung, um Lieferant großer Ketten zu werden. Moderne Web-APIs sind flexibler und leichter anzubinden, während EDI dort seine Stärke behält, wo Branchenstandards und große Handelspartner es verlangen.

Wozu APIs im ERP dienen: Systeme verbinden

Der eigentliche Nutzen einer API zeigt sich, sobald mehrere Systeme zusammenspielen müssen. Ein Onlinehändler betreibt typischerweise einen Shop, verkauft zusätzlich über Marktplätze, wickelt Zahlungen über einen Payment-Dienstleister ab, versendet über einen oder mehrere Paketdienste und übergibt seine Belege an die Buchhaltung oder das Steuerbüro. Ohne APIs müsste jemand Bestellungen abtippen, Lagerbestände in jedem Kanal einzeln pflegen und Versandlabels manuell erzeugen – fehleranfällig und mit jeder verkauften Einheit teurer.

Mit APIs übernimmt das ERP die Rolle der Datendrehscheibe: Neue Bestellungen aus Shop und Marktplatz laufen automatisch ein, Bestände werden über alle Kanäle hinweg synchron gehalten, Zahlungsstatus fließen zurück, Versandaufträge gehen an den Dienstleister und Tracking-Nummern zurück an den Kunden, und die Belege wandern strukturiert in die Finanzbuchhaltung. So entsteht ein durchgängiger Prozess vom Klick des Kunden bis zur verbuchten Zahlung – die Grundlage jeder skalierbaren Multichannel-Abwicklung.

Offene APIs bei der ERP-Auswahl

Weil kaum ein Unternehmen dauerhaft mit nur einem System auskommt, ist die Integrationsfähigkeit eines ERP ein zentrales Auswahlkriterium. Eine offene, gut dokumentierte API entscheidet darüber, ob sich künftige Shops, Tools oder Marktplätze überhaupt anbinden lassen – und zu welchen Kosten. Systeme mit geschlossener oder nur rudimentärer API führen schnell in einen Vendor-Lock-in: Man bleibt beim Anbieter, weil ein Wechsel oder eine Erweiterung technisch kaum machbar wäre.

Achten sollte man bei der Auswahl auf mehrere Punkte: Ist die API öffentlich dokumentiert? Deckt sie die wichtigen Objekte – Artikel, Bestände, Aufträge, Kunden, Belege – lesend und schreibend ab? Gibt es Webhooks für Echtzeit-Ereignisse? Und existieren bereits fertige Anbindungen zu gängigen Shops und Marktplätzen oder eine Middleware, die als Vermittler dient? Ein ERP mit starker API muss man nicht neu erfinden, sondern kann es Schritt für Schritt in eine wachsende Systemlandschaft einbetten.

Authentifizierung und Rate-Limits

Damit nicht jeder beliebig auf Daten zugreift, verlangt jede seriöse API eine Authentifizierung. Das aufrufende System weist sich mit einem Zugangsschlüssel aus – häufig einem API-Key oder einem Token nach dem OAuth-Verfahren –, den man im ERP oder beim Zielsystem einmalig einrichtet. Nur wer den gültigen Schlüssel mitschickt, erhält Antworten; entzieht man den Schlüssel, ist die Verbindung sofort gekappt.

Zusätzlich schützen sich Anbieter mit sogenannten Rate-Limits, also Obergrenzen für die Zahl der Anfragen pro Zeitraum. Sie verhindern, dass ein fehlerhaft programmierter oder überlasteter Client das System lahmlegt. Für die Praxis heißt das: Datenmengen und Synchronisationen müssen so gestaltet sein, dass sie innerhalb der erlaubten Frequenz bleiben – ein Aspekt, den Integrations- und Implementierungsprojekte von Anfang an mitdenken sollten.