Authentifizierung

Sende den API-Schlüssel im Header. Es ist kein Slug in der URL nötig — das Restaurant ergibt sich aus dem Key. Schlüssel legst du unter Einstellungen → API an.

GET /api/v1/menu
Authorization: Bearer gwada_sk_live_…
Accept: application/json

Für Schreibzugriffe (derzeit nur Reservierung) dieselbe Auth mit POST und Content-Type: application/json.

Secret-Key

• Format: gwada_sk_live_…
• Wird beim Erstellen nur einmal im Klartext angezeigt
• Danach nur noch Prefix sichtbar — bei Verlust neuen Key anlegen und den alten widerrufen
• Funktioniert nur, wenn das Restaurant veröffentlicht ist
• Key nur serverseitig speichern — nie in öffentlichen Frontend-Bundles

Module pro Key

Jeder Schlüssel hat eine Modulliste (enabled_modules). Anfragen an nicht freigeschaltete Endpunkte antworten mit 403 module_not_enabled. Modul-IDs:

• menu — Speisekarte
• reservation — Reservierung
• reviews — Bewertungen
• news — News
• events — Events
• gallery — Galerie
• opening_hours — Öffnungszeiten

Domains (optional)

Optional kann pro Key eine Origin-Allowlist gesetzt werden (für Browser-Aufrufe mit Origin-Header). Server-zu-Server ohne Origin bleibt erlaubt, wenn die Liste leer ist. Fremde Origins → 403 origin_forbidden.

Häufige Auth-Fehler

• 401 invalid_api_key — fehlt, falsch oder widerrufen
• 403 module_not_enabled — Modul nicht am Key aktiv
• 403 origin_forbidden — Origin nicht erlaubt
• 403 restaurant_not_published — Restaurant nicht veröffentlicht
• 429 rate_limit_exceeded — Limit pro Key — siehe Rate Limits