Open API (Gastronomie-Software)

#Definition

Eine Open API beschreibt eine Schnittstelle, die ein Software-Anbieter öffentlich zugänglich macht und dokumentiert. Externe Entwickler können nach Anmeldung Daten lesen, Aktionen auslösen oder Ereignisse abonnieren. In der Gastronomie betrifft das vor allem die Kassen, das Reservierungssystem, die Lieferanten-Plattform, das Warenwirtschaftssystem und die Personalsoftware.

Der Unterschied zu einer geschlossenen API liegt nicht in der Technik, sondern im Geschäftsmodell. Eine Open API steht jedem Kunden zur Verfügung, oft mit Self-Service-Onboarding und Dokumentation auf der Anbieter-Webseite. Geschlossene APIs verlangen individuelle Verträge, Partner-Status oder einen Sales-Kontakt. Wer Software für einen Multi-Standort-Betrieb auswählt, sollte die API-Offenheit als Kaufkriterium behandeln.

#Anwendung in Gastro-Software

REST über HTTPS ist heute der Branchenstandard. Eine typische Anfrage sieht aus wie GET /v1/orders?location=42&from=2026-05-27T00:00. Die Antwort kommt als JSON, paginiert in Blöcken von 50 bis 200 Einträgen. Methoden sind GET für Abfragen, POST für neue Einträge, PUT für Updates und DELETE für Löschungen. Diese Konventionen sind branchenübergreifend gleich, der Lernaufwand für Entwickler ist gering.

Authentifizierung läuft fast immer über OAuth 2.0 mit Client-Credentials. Du hinterlegst eine Client-ID und ein Secret, tauschst sie gegen einen Access-Token und schickst diesen im Authorization-Header mit. Tokens werden alle paar Minuten bis Stunden erneuert. Ältere APIs nutzen statische API-Keys, das gilt heute als überholt, weil Rotation und Widerruf umständlich sind. Für die Verbindung mit der POS-Schnittstelle ist OAuth 2.0 Voraussetzung.

Rate-Limits sind der unsichtbare Engpass. Eine moderne Gastro-API erlaubt typischerweise 100 bis 1.000 Requests pro Minute pro Key. Bei zwölf Standorten und engmaschigem Polling ist das Limit schnell erreicht. Saubere Adapter respektieren das Limit, queuen überschüssige Anfragen und führen Exponential-Backoff bei HTTP 429 durch. Anbieter mit harten, niedrigen Limits zwingen ihre Integrationspartner ins Webhook-Modell.

Webhooks ergänzen die REST-Sicht durch Push-Logik. Statt alle paar Minuten zu fragen, abonnierst du Ereignisse wie "Bestellung erstellt" oder "Inventur abgeschlossen". Der Anbieter schickt dann aktiv einen POST-Request an deinen Endpunkt. Das spart Bandbreite und liefert Daten in Sekunden statt Minuten. In der Praxis kombinierst du beide Muster.

Eine dokumentierte OpenAPI-Spezifikation in YAML oder JSON ist heute Pflicht. Sie beschreibt alle Endpunkte, Felder, Typen und Fehlercodes maschinenlesbar. Aus der Spec lassen sich SDKs, Test-Stubs und Dokumentationsseiten generieren. Anbieter ohne OpenAPI-Spec haben oft veraltete Stack-Logik und sind in Integrationsprojekten teurer.

Versionierung läuft über den URL-Pfad wie /v1/ oder /v2/. Breaking Changes kommen in einer neuen Version, alte Versionen laufen mindestens sechs bis zwölf Monate parallel. Anbieter, die ihre API ohne Vorwarnung brechen, sind ein Risiko für deinen Stack. Achte beim Vertrag auf eine Deprecation-Policy.

Eine offene API verändert die Position deines Stack-Anbieters. Software mit Open API lässt sich in vorhandene ERP-Landschaften einbinden, mit BI-Tools verbinden und durch eigene Auswertungen ergänzen. Wer eine geschlossene Plattform kauft, kommt im Zweifel nur über CSV-Export oder bezahlte Custom-Integrationen weiter. Diese Lock-in-Effekte werden beim Kauf oft unterschätzt und zeigen sich erst Jahre später bei einer Migration.

Die Stack-Vorteile sind in einem Multi-Standort-Betrieb besonders deutlich. Heterogene Kassen, mehrere Lieferanten-Plattformen und unterschiedliche Personal-Systeme müssen in ein gemeinsames Reporting fließen. Ohne offene APIs entstehen manuelle CSV-Brücken, die jeden Monat brechen. Mit offenen APIs läuft die Konsolidierung automatisiert und Datenqualität bleibt stabil. Der Aufwand für Reporting sinkt typisch von mehreren Stunden pro Woche auf wenige Minuten Monitoring-Zeit.

Auch die Auswahl von Software-Anbietern verändert sich. Open API ist ein hartes Kaufkriterium, wenn dein Konzept auf Skalierung ausgelegt ist. Anbieter ohne dokumentierte API werden in modernen Auswahlverfahren in der Regel disqualifiziert oder mit hohen Risiko-Abschlägen versehen. Ein Vendor-Lock-in ohne API-Zugang reduziert deine Verhandlungsposition bei Vertragsverlängerungen erheblich.

#Häufige Fehler

• API-Keys werden im Source-Code abgelegt statt in einem Secret-Manager. Wer den Code sieht, sieht auch den Key, und kann auf Stammdaten zugreifen.
• Rate-Limits werden ignoriert. Bei Lastspitzen wirft die API HTTP 429 und Daten gehen verloren, weil keine Retry-Logik greift.
• Webhook-Endpunkte werden ohne HMAC-Signatur betrieben. Theoretisch kann jeder fremde Daten in dein System schieben, ein Sicherheits- und DSGVO-Risiko.
• Pagination wird übersehen. Bei großen Backfill-Läufen werden nur die ersten 50 Einträge gelesen, der Rest fehlt im Reporting.
• Time-Zones werden inkonsistent gehandhabt. Ein Endpunkt liefert UTC, der nächste lokale Zeit. Tagesabschlüsse landen am falschen Datum.
• Sandbox- und Produktiv-Umgebung werden vertauscht. Tests laufen versehentlich auf echten Daten oder Live-Stammdaten werden im Sandbox-Modus angepasst und gehen verloren.
• Fehler-Codes werden nicht differenziert behandelt. HTTP 401 (Auth abgelaufen) und HTTP 429 (Rate-Limit) brauchen unterschiedliche Reaktionen, eine Pauschal-Retry-Logik macht beides schlimmer.

Ein Praxisbeispiel zeigt die Bandbreite. Eine deutsche Burger-Kette mit 18 Standorten betrieb drei verschiedene Kassensysteme parallel. Lightspeed mit Open API auf dreizehn Standorten, Orderbird mit Open API auf drei Standorten, und Vectron ohne moderne API auf zwei Standorten. Die ersten sechzehn Standorte konnten innerhalb von vier Wochen über REST und Webhook angebunden werden. Die zwei Vectron-Standorte brauchten einen SFTP-Datei-Job mit nächtlichem Export, weil keine offene API verfügbar war. Die Latenz unterschied sich entsprechend stark. Echtzeit auf sechzehn Standorten, Tagesverzögerung auf zwei.

Der Effekt auf das tägliche Reporting war messbar. Die Wareneinsatzquote konnte für sechzehn Standorte täglich nach Schichtende ausgewertet werden. Standortleiter erhielten morgens ihre Soll-Ist-Werte automatisch. Für die zwei Legacy-Standorte musste der Vergleich tagesverzögert laufen. Im Blog-Beitrag zu Kennzahlen Gastronomie wird der Hebel solcher Reporting-Cycles näher beleuchtet.

#So unterstützt Heptic

Heptic Integrationen bietet eine vollständig dokumentierte Open API für Bons, Artikel, Inventur, Personal und Reporting. REST über HTTPS, OAuth 2.0, Webhooks für die wichtigsten Events und eine OpenAPI-Spec für den schnellen Einstieg. Rate-Limits sind klar dokumentiert, Sandbox-Accounts stehen für Tests bereit. So bindest du deinen bestehenden Stack aus Kassen, ERP und BI-Tools in wenigen Tagen statt Wochen an.

Häufige Fragen

Was unterscheidet eine Open API von einer geschlossenen API?

Eine Open API ist öffentlich dokumentiert und für jeden Entwickler zugänglich. Du brauchst einen Account und einen API-Key, dann kannst du loslegen. Geschlossene APIs sind nur Partnern oder dem Anbieter selbst zugänglich, oft mit individuellem Vertrag und NDA. Open APIs senken Integrationskosten und beschleunigen Anbindungen. Geschlossene APIs sind ein typisches Lock-in-Muster und sollten beim Software-Kauf hinterfragt werden.

Welche Standards sollte eine moderne Gastronomie-API erfüllen?

REST über HTTPS mit JSON als Format, OAuth 2.0 für die Authentifizierung, Webhooks für Echtzeit-Events und klar dokumentierte Rate-Limits. Dazu eine OpenAPI-Spezifikation als maschinenlesbare Dokumentation und ein Sandbox-Account zum Testen. Versionierung über den URL-Pfad wie /v1/ oder /v2/ ist Standard. SDKs in Python, JavaScript und PHP erleichtern die Anbindung, sind aber kein Muss.

Wie wichtig sind Rate-Limits in der Praxis?

Sehr wichtig. Typische Limits liegen bei 100 bis 1.000 Requests pro Minute pro API-Key. Wer ohne Throttling pollt, läuft schnell in HTTP 429 und Daten gehen verloren. Saubere Integrationen respektieren Rate-Limits, queuen Requests und nutzen Exponential-Backoff bei Fehlern. Eine API ohne dokumentierte Limits ist ein Risiko, weil der Anbieter ohne Vorwarnung Zugang einschränken kann.

Zuletzt aktualisiert: Mai 2026