Anmelden um den Slug und den veröffentlichbaren Schlüssel Ihrer Location in jedem Beispiel zu sehen.
Ihr Konto hat noch keine Location, die Beispiele behalten daher ihre Platzhalter. Abmelden
Angemeldet als · . Legen Sie in der Konsole einen veröffentlichbaren Schlüssel an und laden Sie die Seite neu, um ihn hier zu sehen. Abmelden
Angemeldet als · . Die Beispiele zeigen den veröffentlichbaren Schlüssel Ihrer Location. Abmelden
Entwicklerdokumentation
Authentifizierung
So funktionieren BookDinePlay-API-Schlüssel – veröffentlichbar oder geheim, wo welcher erlaubt ist, wie man ihn sendet und was die API ablehnt.
Jeder Aufruf von /api/venues/** muss einen API-Schlüssel mitführen. Eine anonyme Stufe gibt es nicht. Ein Schlüssel ist an einen Betrieb gebunden: Er funktioniert für dessen Routen und wird für jeden anderen abgelehnt.
Zwei Schlüsseltypen
Veröffentlichbar bdp_pk_… |
Geheim bdp_sk_… |
|
|---|---|---|
| Liegt in | Ihrem öffentlichen HTML, dem Widget, dem WordPress-Plugin | Nur auf Ihrem Server |
| Geschützt durch | Eine Origin-Liste, die Sie pflegen | Geheimhaltung (als SHA-256-Hash gespeichert; einmalig beim Anlegen angezeigt) |
Origin-Header |
Pflicht – die Anfrage kam aus einem Browser | Verboten – ein Browser darf ihn nie besitzen |
| Typischer Aufrufer | Das Buchungswidget im Browser eines Gastes | Ihr Backend, per .NET-SDK oder purem HTTP |
Schlüssel legen Sie in der Konsole unter Location → API-Schlüssel an und widerrufen sie dort (app.bookdineplay.com/operator/venue). Der Wert eines veröffentlichbaren Schlüssels ist dort jederzeit sichtbar; der Wert eines geheimen Schlüssels genau einmal.
Schlüssel senden
Beide Header funktionieren; Widget und SDK verwenden den ersten:
X-BookDinePlay-Key: bdp_pk_your_publishable_key
Authorization: Bearer bdp_pk_your_publishable_keySetzen Sie einen Schlüssel nie in einen Query-String. Ein Schlüssel in einer URL landet in Zugriffsprotokollen, Referer-Headern und im Browserverlauf – und die API liest ihn dort ohnehin nicht.
curl
curl "https://api.bookdineplay.com/api/venues/your-venue" \
-H "X-BookDinePlay-Key: bdp_pk_your_publishable_key" \
-H "Origin: https://www.your-venue.example"JavaScript
const response = await fetch('https://api.bookdineplay.com/api/venues/your-venue', {
headers: { 'X-BookDinePlay-Key': 'bdp_pk_your_publishable_key' }
});
const venue = await response.json();C#
// Program.cs – serverseitig, mit einem GEHEIMEN Schlüssel aus der Konfiguration, nie als Literal.
builder.Services.AddBookDinePlayClient(
new Uri("https://api.bookdineplay.com"),
builder.Configuration["BookDinePlay:ApiKey"]!);
// Überall, wo IBookDinePlayClient injiziert wird:
var venue = await client.GetVenueAsync("your-venue", cancellationToken);Origins
Ein veröffentlichbarer Schlüssel trägt eine Liste erlaubter Origins. Eine Origin ist schema://host[:port] – https://www.your-venue.example, kein Pfad und kein bloßer Hostname. Verglichen wird exakt auf Schema und Host; auch der Port muss übereinstimmen, außer der Eintrag endet auf :*:
http://localhost:*
https://staging.your-venue.example:*:* bedeutet „jeder Port auf genau diesem Schema und Host“ – für die lokale Entwicklung auf localhost oder einen Staging-Host, der zwischen Ports wechselt. Es ist der einzige Platzhalter; für Schema, Host oder Subdomain gibt es keinen.
Eine Anfrage, deren Origin auf der Liste steht, bekommt genau diese Origin in Access-Control-Allow-Origin zurück und die angefragten Daten; eine andere bekommt 403 mit einem Problem-Body, den der Browser trotzdem lesen kann – die API spiegelt Ihre Origin bei Ablehnungen genau deshalb zurück, damit Sie den type sehen –, aber keine Betriebsdaten. Die Origin-Liste ist die CORS-Richtlinie – eine separate Einstellung gibt es nicht.
Was die API ablehnt
Jede Ablehnung ist eine RFC-7807-Problem-Antwort, deren type mit dem Grund unten endet; jeder Grund hat einen eigenen Abschnitt unter Fehler.
| Status | type-Suffix |
Wann | Abhilfe |
|---|---|---|---|
| 401 | missing-api-key |
Kein Schlüssel in einem der beiden Header | Schlüssel senden |
| 401 | invalid-api-key |
Unbekannter, widerrufener oder falsch präfixierter Schlüssel | Schlüssel in der Konsole prüfen |
| 403 | venue-mismatch |
Der Schlüssel gehört zu einem anderen Betrieb als dem in der Route | Schlüssel dieses Betriebs verwenden |
| 403 | origin-not-allowed |
Veröffentlichbarer Schlüssel; die Origin der Anfrage steht nicht auf seiner Liste |
Schlüssel anlegen, der die Origin enthält – die Liste steht mit dem Anlegen fest |
| 403 | secret-key-from-browser |
Geheimer Schlüssel und ein Origin-Header – die Anfrage kam aus einem Browser |
Im Browser einen veröffentlichbaren Schlüssel verwenden |
| 403 | publishable-key-without-origin |
Veröffentlichbarer Schlüssel ohne Origin – die Anfrage kam von einem Server |
Auf Servern einen geheimen Schlüssel verwenden |
Unbekannte und widerrufene Schlüssel bekommen absichtlich dieselbe Antwort: Niemand kann herausfinden, welcher Fall vorliegt.
{
"type": "https://bookdineplay.com/docs/api/errors/origin-not-allowed",
"title": "Forbidden",
"status": 403,
"detail": "This origin is not on the API key's list of allowed origins."
}Schlüssel rotieren
Schlüssel können nebeneinander existieren, Rotation braucht daher nie eine Auszeit:
- Neuen Schlüssel desselben Typs mit denselben Origins anlegen.
- Auf Website oder Server ausrollen.
- Alten Schlüssel in der Konsole widerrufen. Der Widerruf wirkt sofort.
Nächste Schritte
- Schnellstart – einen veröffentlichbaren Schlüssel im Widget einsetzen.
- .NET-SDK – serverseitige Nutzung mit einem geheimen Schlüssel.