Fehler

Lehnt die API eine Anfrage wegen des Schlüssels ab, ist der type im Problem-Body https://bookdineplay.com/docs/api/errors/<reason>, und <reason> ist einer der neun Abschnitte auf dieser Seite. Folgen Sie der URL, landen Sie hier. Fünfundzwanzig weitere type-URLs landen ebenfalls hier: das Tarifproblem, die zwei Idempotenz-Probleme (gemeinsam für Reservierungsanlage, Event-Anmeldung, Ticket-Checkout und Gutschein-Checkout), die drei Probleme bei Event-Anmeldung und Erstattung, die zwei Probleme bei der Reservierungsstornierung, die zwölf Gutschein-Probleme sowie die fünf Abrechnungs-, Konto- bzw. Auszahlungsprobleme weiter unten. Jede andere Ablehnung – Validierung, eine fehlende Location, ein vergebener Slot – steht am Ende.

missing-api-key

401. Die Anfrage erreichte einen Endpunkt unter /api/venues/** ohne X-BookDinePlay-Key- und ohne Authorization: Bearer-Header. Meist wurde der Header auf der falschen Client-Instanz gesetzt oder ein Proxy hat ihn entfernt. Abhilfe: Senden Sie den Schlüssel bei jeder Anfrage – siehe Einen Schlüssel senden.

{
  "type": "https://bookdineplay.com/docs/api/errors/missing-api-key",
  "title": "Unauthorized",
  "status": 401,
  "detail": "An API key is required. Send it in the 'X-BookDinePlay-Key' header or an 'Authorization: Bearer' header.",
  "traceId": "0HNOJ52B2L9BB"
}

invalid-api-key

401. Ein Schlüssel wurde gesendet, aber kein aktiver Schlüssel passt dazu: Er wurde falsch abgetippt, in der Konsole unter Location → API-Schlüssel widerrufen oder rotiert, und der alte Wert ist noch im Einsatz. Abhilfe: Kopieren Sie den aktuellen Schlüssel aus der Konsole; beim Rotieren zuerst den neuen Schlüssel ausrollen, dann den alten widerrufen.

venue-mismatch

403. Der Schlüssel ist gültig, aber an eine andere Location gebunden als der {venueSlug} in der URL. Schlüssel gelten pro Location; eine Website, die mehrere Locations einbettet, braucht je einen Schlüssel (genau dafür gibt es das Attribut key des WordPress-Plugins). Abhilfe: Verwenden Sie den Schlüssel, der unter der aufgerufenen Location erstellt wurde.

origin-not-allowed

403. Ein veröffentlichbarer Schlüssel wurde von einem Origin gesendet, der nicht auf seiner Liste steht. Typische Ursachen: Die Website ist auf eine neue Domain umgezogen, www gegenüber der nackten Domain, http gegenüber https oder ein Staging-Host. Abhilfe: Tragen Sie den exakten Origin (Schema, Host und ggf. Port) unter Location → API-Schlüssel ein oder ergänzen Sie für die lokale Entwicklung ein Port-Wildcard :* – siehe Origins.

{
  "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.",
  "traceId": "0HNOJ52B2L9BD"
}

secret-key-from-browser

403. Ein geheimer Schlüssel (bdp_sk_…) kam zusammen mit einem Origin-Header an, den nur Browser senden. Ein geheimer Schlüssel im Browser ist ein veröffentlichtes Geheimnis, daher wird die Anfrage sofort abgelehnt statt bedient. Abhilfe: Widerrufen Sie diesen Schlüssel jetzt, erstellen Sie einen veröffentlichbaren Schlüssel für den Browser und behalten Sie geheime Schlüssel auf dem Server.

publishable-key-without-origin

403. Ein veröffentlichbarer Schlüssel (bdp_pk_…) kam ohne Origin-Header an. Veröffentlichbare Schlüssel sind durch ihre Origin-Liste geschützt, und ohne Origin gibt es nichts zu prüfen. So sieht ein serverseitiger Aufruf mit einem veröffentlichbaren Schlüssel aus. Abhilfe: Verwenden Sie auf dem Server einen geheimen Schlüssel; kommt der Aufruf wirklich aus einem Browser, wird der Origin-Header automatisch ergänzt – fehlt er, kam die Anfrage nicht von einem Browser.

app-key-from-browser

403. Der App-Schlüssel von BookDinePlay (bdp_ak_…, siehe Der App-Schlüssel von BookDinePlay) kam zusammen mit einem Origin-Header an. Der App-Schlüssel gehört zu den nativen Apps von BookDinePlay aus den Stores, die keinen Origin senden; ein Browser, der ihn vorzeigt, ist nicht die App, und der Schlüssel erreicht jede Location – daher wird die Anfrage sofort abgelehnt. Abhilfe: Verwenden Sie im Browser den veröffentlichbaren Schlüssel Ihrer eigenen Location.

platform-key-required

403. Der eigene Schlüssel einer Location (bdp_pk_… oder bdp_sk_…) wurde an GET /api/venues gesendet, das Location-Verzeichnis. Das Verzeichnis listet andere Locations auf, und dafür ist der Schlüssel einer einzelnen Location nicht gedacht; nur die eigenen Apps von BookDinePlay rufen es auf. Abhilfe: Rufen Sie stattdessen die Routen Ihrer eigenen Location auf, /api/venues/{venueSlug}/….

rate-limited

429. Den App-Schlüssel von BookDinePlay teilen sich alle Installationen der Apps aus den Stores, daher hat er ein festes Zeitfenster-Limit pro Schlüssel. Der Retry-After-Header sagt, wie viele Sekunden zu warten ist. Für die Schlüssel einer Location gilt dieses Limit nicht. Abhilfe: Die angegebene Zeit warten und erneut versuchen – nicht in einer engen Schleife wiederholen.

{
  "type": "https://bookdineplay.com/docs/api/errors/rate-limited",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Too many requests. Please wait a minute and try again.",
  "traceId": "0HNOJ52B2L9BE"
}

Tarif- und Berechtigungsprobleme

Keine Schlüsselprobleme: Der Tarif des Mandanten deckt nicht ab, was die Anfrage braucht.

feature-not-in-plan

403. Kommt bei der Operator-API vor (eine Ressource vom Spieltyp anlegen oder bearbeiten, den Raumplan öffnen, Mitarbeiter verwalten oder Events verwalten, wenn der Tarif sie nicht enthält), bei POST /reservations für einen Ressourcentyp, den der Tarif des Mandanten nicht anbietet, bei der öffentlichen Route POST /events/{eventSlug}/registrations, wenn der Tarif der Location keine Events enthält – die Event-Liste antwortet bei einem solchen Tarif mit [] und das Detail mit 404, sodass nur ein Gast, der noch eine Event-URL hat, dieses Problem erreicht –, sowie bei POST /payment-intents, wenn der Tarif keine Online-Zahlungen oder Anzahlungen enthält. Die Checkout-Route für bezahlte Tickets antwortet damit nie: Fehlt der Ticketverkauf im Tarif, fällt das unter ticket-sales-not-enabled, sodass ein Gast nie erfährt, welche der drei Ursachen zutrifft. Das Buchungs-Widget selbst löst feature-not-in-plan nie aus, weil die Verfügbarkeit Ressourcentypen, die ein Starter-Tarif nicht erlaubt, bereits weglässt. requiredPlan nennt den Tarif (Pro oder Premium), der die Funktion freischaltet. Abhilfe: den Tarif des Mandanten hochstufen – in der Konsole unter Ihr Tarif oder über PUT /api/admin/tenants/{id}.

{
  "type": "https://bookdineplay.com/docs/api/errors/feature-not-in-plan",
  "title": "Feature not in plan",
  "status": 403,
  "detail": "This feature requires the Pro plan or higher.",
  "requiredPlan": "Pro",
  "traceId": "0HNOJ52B2L9BE"
}

Welcher Tarif was freischaltet – damit Sie der Location sagen können, worauf sie hochstufen muss. requiredPlan nennt immer einen davon:

Was die Tarife kosten, steht auf der Preisseite.

Probleme bei der Event-Anmeldung

Ebenfalls keine Schlüsselprobleme: Das Anmeldefenster des Events, der Stand des Online-Ticketverkaufs oder die Erstattungsregel einer bezahlten Anmeldung lehnt eine gültige Anfrage ab. Die ersten beiden kommen von POST /api/venues/{venueSlug}/events/{eventSlug}/registrations und der Ticket-Checkout-Route; das dritte kommt von der eigenen Storno-Route des Gasts.

registration-closed

409. Das Anmeldefenster ist geschlossen. reason nennt den Grund, und das Event-Detail meldet denselben Wert in registration.reason, noch bevor Sie es versuchen:

Eine Anmeldung kann mit sold-out abgelehnt werden, obwohl das eben gelesene Detail noch Plätze zeigte: Ein anderer Gast hat die letzten dazwischen genommen. Nehmen Sie das Problem als Wahrheit und das Detail als Hinweis. Der JavaScript-Client hebt reason und remaining auf den Fehler (Fehler); das .NET-SDK stellt sie als Reason und Remaining an BookDinePlayApiException bereit (.NET-SDK).

{
  "type": "https://bookdineplay.com/docs/api/errors/registration-closed",
  "title": "Registration closed",
  "status": 409,
  "detail": "Registration for this event has closed.",
  "reason": "closed",
  "traceId": "0HNOK3A31C71T"
}

ticket-sales-not-enabled

409. Das Event ist Paid, und die Location kann gerade keine Tickets online verkaufen. Das ist die eine Antwort für drei verschiedene Ursachen – der Tarif des Mandanten enthält keinen Ticketverkauf, der Tarif enthält ihn, aber das Stripe-Connect-Auszahlungskonto der Location ist noch nicht Enabled, oder das Event selbst ist nicht Paid – absichtlich zu einem Problem zusammengefasst, damit ein Gast nie erfährt, welche davon zutrifft; die Location sieht den genauen Grund stattdessen in der Konsole (die Karte Abrechnung → Auszahlungen, oder der Hinweis im Event-Editor). Bei der Anmeldung gilt das nur, solange das Anmeldefenster des Events offen ist – ein bezahltes Event mit geschlossenem Fenster antwortet zuerst mit registration-closed, genau wie ein kostenloses Event; die Checkout-Route antwortet unabhängig vom Fenster so. Abhilfe: nichts auf Ihrer Seite – zeigen Sie eine allgemeine „gerade nicht verfügbar“-Meldung, wie es das Events-Widget tut, und überlassen Sie den Verkauf den anderen Kanälen der Location.

{
  "type": "https://bookdineplay.com/docs/api/errors/ticket-sales-not-enabled",
  "title": "Ticket sales not enabled",
  "status": 409,
  "detail": "Online ticket sales are not enabled for this venue yet.",
  "traceId": "0HNOK3A31C71U"
}

refund-not-available

409. Ein Gast wollte eine bezahlte Anmeldung über seinen eigenen Storno-Link stornieren, aber die Erstattungsregel des Events erlaubt gerade keine Online-Erstattung – die Location hat „keine Online-Erstattung“ eingestellt, oder das Erstattungsfenster (hoursBeforeStart vor Beginn) ist bereits vorbei. Die Anmeldung bleibt unverändert: Nichts wird storniert und keine Zahlung angefasst, der Gast kann die Location also weiterhin direkt fragen. GET /api/registrations/{cancelToken} meldet dasselbe schon vorab als canCancel: false mit einem erklärenden cancelNote, sodass eine Integration nicht erst stornieren muss, um es herauszufinden. Abhilfe: nichts auf Ihrer Seite – zeigen Sie den Hinweis und verweisen Sie den Gast an die Location; erstatten kann von hier aus nur die Location (aus der Teilnehmerliste des Events) oder der BookDinePlay-Support.

{
  "type": "https://bookdineplay.com/docs/api/errors/refund-not-available",
  "title": "Refund not available",
  "status": 409,
  "detail": "Diese Anmeldung kann nicht online erstattet werden. Bitte wenden Sie sich direkt an die Location.",
  "traceId": "0HNOK3A31C71X"
}

reservation-cancellation-not-allowed

409. Ein Gast wollte eine Buchung über seinen eigenen Storno-Link stornieren, aber die Storno-Richtlinie der Location erlaubt gerade keine Online-Stornierung – die Location hat die Selbststornierung durch Gäste komplett abgeschaltet, oder die Frist (hoursBeforeStart vor Beginn der Buchung) ist bereits abgelaufen. Die Reservierung bleibt unverändert: Nichts wird storniert. GET /api/reservations/{cancelToken} meldet dasselbe schon vorab als canCancel: false mit einem erklärenden cancelNote, sodass eine Integration nicht erst stornieren muss, um es herauszufinden. Abhilfe: nichts auf Ihrer Seite – zeigen Sie den Hinweis und verweisen Sie den Gast direkt an die Location.

{
  "type": "https://bookdineplay.com/docs/api/errors/reservation-cancellation-not-allowed",
  "title": "Reservation cancellation not allowed",
  "status": 409,
  "detail": "Diese Buchung kann nicht mehr online storniert werden. Bitte wenden Sie sich direkt an die Location.",
  "traceId": "0HNOK3A31C71Y"
}

reservation-deposit-not-refundable

409. Ein Gast wollte eine Buchung über seinen eigenen Storno-Link stornieren, aber die Anzahlung der Buchung wurde online bezahlt und die Location hat festgelegt, dass eine Anzahlung im Gespräch geklärt wird und nicht über einen Storno-Link. Eine Stornierung würde den Slot freigeben, ohne dass jemand über das Geld entschieden hat – deshalb wird sie abgelehnt. Bewusst ein anderer type als reservation-cancellation-not-allowed: Die Website einer Location muss hier etwas anderes sagen ("wir müssen Ihre Anzahlung klären, bitte rufen Sie uns an") als bei einer gewöhnlichen Fristablehnung ("zu kurzfristig vor Ihrer Buchung"). Die Reservierung bleibt unverändert. GET /api/reservations/{cancelToken} meldet dasselbe schon vorab als canCancel: false mit einem erklärenden cancelNote. Abhilfe: nichts auf Ihrer Seite – zeigen Sie den Hinweis und verweisen Sie den Gast direkt an die Location. Das ist eine Einstellung der Location: Ein Betreiber, der in seiner Storno-Richtlinie die Anzahlung bei einer Gast-Stornierung erstatten (oder einbehalten) lässt, erzeugt dieses Problem gar nicht mehr.

{
  "type": "https://bookdineplay.com/docs/api/errors/reservation-deposit-not-refundable",
  "title": "Reservation deposit not refundable",
  "status": 409,
  "detail": "Für diese Buchung wurde eine Anzahlung geleistet, die noch nicht online erstattet werden kann. Bitte wenden Sie sich direkt an die Location.",
  "traceId": "0HNOK3A31C71Z"
}

reservation-refund-failed

502. Der umgekehrte Fall: Die Location erstattet Anzahlungen bei einer Gast-Stornierung sehr wohl, aber die Erstattung selbst ist beim Zahlungsanbieter fehlgeschlagen. Es wurde nichts storniert und nichts verzeichnet – die Erstattung läuft genau deshalb vor der Stornierung, damit ein Fehlschlag die Buchung des Gastes unangetastet lässt, statt seinen Slot freizugeben, während sein Geld liegen bleibt. Der 502 statt eines 409 ist der Punkt: Das ist keine festgelegte Regel der Location, sondern eine vorübergehende Störung weiter oben – ein erneuter Versuch lohnt sich wirklich, und Ihre Oberfläche darf dem Gast nicht sagen, seine Location erlaube das nicht. Abhilfe: Bitten Sie den Gast, es gleich noch einmal zu versuchen; schlägt es weiterhin fehl, braucht das Zahlungskonto der Location Aufmerksamkeit und der Gast sollte sie direkt kontaktieren.

{
  "type": "https://bookdineplay.com/docs/api/errors/reservation-refund-failed",
  "title": "Reservation refund failed",
  "status": 502,
  "detail": "Wir konnten Ihre Anzahlung gerade nicht erstatten — Ihre Buchung bleibt deshalb unverändert. Bitte versuchen Sie es gleich noch einmal.",
  "traceId": "0HNOK3A31C720"
}

Idempotenz-Probleme

Kein Schlüsselproblem und kein Tarifproblem: Vier Routen akzeptieren einen optionalen Idempotency-Key-Header – POST /api/venues/{venueSlug}/reservations, POST /api/venues/{venueSlug}/events/{eventSlug}/registrations, die Ticket-Checkout-Route und der Gutschein-Checkout – und dieser Abschnitt zeigt die zwei Wege, wie dieser Header selbst abgelehnt werden kann oder Sie warten lässt.

idempotency-key-reused

409. Der gesendete Idempotency-Key wurde bereits – innerhalb der letzten 24 Stunden, auf derselben Route, für diese Location, von Ihrem eigenen Konto – für einen Request verwendet, dessen Body sich anders hasht als dieser. Durch diesen Aufruf wurde nichts angelegt: Ein übereinstimmender Body hätte stattdessen die Original-Buchung, -Anmeldung oder den -Checkout wiedergegeben, statt diese Ablehnung überhaupt zu erreichen – sie feuert also nur bei einer echten Abweichung. Übliche Ursache ist ein Key, der den Versuch überlebt hat, für den er erzeugt wurde – wiederverwendet für zwei verschiedene Anfragen, oder ein Formular, das versehentlich mit geänderten Angaben unter demselben Key erneut abgeschickt wurde. Bei der Ticket-Checkout-Route bleibt die Checkout-Sitzung des ersten Versuchs dabei unangetastet: Ein abweichender Aufrufer ist nicht ihr Eigentümer, deshalb rührt diese Ablehnung sie niemals an. Abhilfe: pro Versuch einen frischen Key erzeugen (siehe Sicher wiederholen mit Idempotency-Key), und unter einem bereits verwendeten Key immer nur den identischen Body erneut senden.

{
  "type": "https://bookdineplay.com/docs/api/errors/idempotency-key-reused",
  "title": "Idempotency key reused",
  "status": 409,
  "detail": "This Idempotency-Key was already used for a different request.",
  "traceId": "0HNOK3A31C723"
}

checkout-in-progress

409. Nur beim Ticket-Checkout. Für diese Anfrage existiert ein aktiver Idempotency-Key-Claim, aber die Checkout-Sitzung, für die er steht, ist noch nicht fertig angelegt – der Platz wird reserviert, bevor Stripe überhaupt aufgerufen wird, sodass ein identischer Wiederholungsversuch, der in die kurze Lücke fällt, während Stripe noch antwortet, die Checkout-URL noch nicht erhalten kann. Realistisch kann nur ein wirklich gleichzeitiger erneuter Aufruf (zwei Anfragen gleichzeitig unter demselben Key) das beobachten; ein sequenzieller Wiederholungsversuch – der übliche Fall, nachdem der erste Versuch tatsächlich zurückgekehrt ist – nie. Abhilfe: einen Moment warten und mit demselben Key erneut versuchen; er gibt dann entweder den abgeschlossenen Checkout wieder oder startet, falls der Stripe-Aufruf des ersten Versuchs selbst fehlgeschlagen ist, einen neuen.

{
  "type": "https://bookdineplay.com/docs/api/errors/checkout-in-progress",
  "title": "Checkout in progress",
  "status": 409,
  "detail": "Eine Checkout-Sitzung für diese Anfrage wird gerade noch erstellt. Bitte versuchen Sie es gleich noch einmal.",
  "traceId": "0HNOK3A31C725"
}

Abrechnungs-, Konto- und Auszahlungsprobleme

Hier geht es nicht um die Anfrage: Es ist das BookDinePlay-Konto der Location oder ihr verbundenes Stripe-Auszahlungskonto, das ablehnt.

tenant-suspended

403. Das Konto der Location wird nicht bedient. Entweder ist ihr Abonnement ausgelaufen (unbezahlt oder gekündigt), BookDinePlay hat es gesperrt, oder eine Selbstregistrierung wurde nie bezahlt – alle drei antworten mit demselben Problem, weil keines davon etwas ist, worauf eine Integration oder ein Gast reagieren könnte, und eine Unterscheidung den Abrechnungsstand der Location jedem preisgeben würde, der die API erreicht. Jede Route unter /api/venues/** antwortet so, Lesezugriffe eingeschlossen; die Routen mit eigenem Gast-Credential (GET /api/tickets/{code}, POST /api/event-registrations/{cancelToken}/cancel, GET /api/qr/{token} und die Gutscheinabfrage) funktionieren weiter, damit ein gedruckter QR-Code oder ein per E-Mail zugesandtes Ticket nicht an einer abgelaufenen Karte der Location scheitert. Abhilfe: auf Ihrer Seite nichts – blenden Sie das Buchungs-Widget aus und zeigen Sie die Telefonnummer der Location; die Location regelt es unter Abrechnung, und die Route antwortet Sekunden später wieder.

{
  "type": "https://bookdineplay.com/docs/api/errors/tenant-suspended",
  "title": "Tenant suspended",
  "status": 403,
  "detail": "Diese Location nimmt derzeit keine Buchungen an. Bitte wenden Sie sich direkt an die Location.",
  "traceId": "0HNOK3A31C71V"
}

billing-managed-by-stripe

409. Nur bei PUT /api/admin/tenants/{id}: plan und status des Mandanten gehören zu seinem Stripe-Abonnement, deshalb ändert die Admin-Oberfläche keines von beiden von Hand – beide werden bei jeder Synchronisierung aus dem Abonnement neu abgeleitet, eine Änderung hier würde also vom nächsten Webhook stillschweigend zurückgesetzt. Die bereits gesetzten Werte mitzusenden ist keine Änderung, ein anderes Feld lässt sich also weiterhin bearbeiten. Abhilfe: das Abonnement ändern (genau das tut Tarif wechseln für den Betreiber), oder den Mandanten in derselben Anfrage mit billing: "Manual" auf manuelle Abrechnung umstellen – das nimmt dem Abonnement die Hoheit über den Tarif, kündigt es bei Stripe aber nicht; der notice der Antwort sagt das.

{
  "type": "https://bookdineplay.com/docs/api/errors/billing-managed-by-stripe",
  "title": "Billing managed by Stripe",
  "status": 409,
  "detail": "Tarif und Kontostatus dieses Mandanten werden über sein Stripe-Abonnement verwaltet. Ändern Sie das Abonnement oder stellen Sie den Mandanten zuerst auf manuelle Abrechnung um.",
  "traceId": "0HNOK3A31C71W"
}

payouts-not-connected

409. Der Tarif des Mandanten und die eigenen Schalter der Location erlauben Online-Zahlungen, aber das Stripe-Connect-Auszahlungskonto der Location ist noch nicht Enabled – entweder wurde das Onboarding nie gestartet, läuft gerade, oder Stripe hat es nach einem Prüfungsproblem eingeschränkt. Wird von POST /api/venues/{venueSlug}/payment-intents für eine Reservierungsanzahlung zurückgegeben. Die Checkout-Route für Gast-Tickets antwortet damit nie direkt: Sie fasst dieselbe Ursache stattdessen unter ticket-sales-not-enabled zusammen, sodass ein Gast nie erfährt, welche der drei Ursachen zutrifft – nur der Betreiber sieht sie, in der Karte Abrechnung → Auszahlungen der Konsole. Abhilfe: nichts auf Ihrer Seite – überspringen Sie den Anzahlungsschritt und behandeln Sie die Reservierung als von der Location bestätigt; die Location verbindet (oder vervollständigt) ihr Auszahlungskonto in der Konsole.

{
  "type": "https://bookdineplay.com/docs/api/errors/payouts-not-connected",
  "title": "Payouts not connected",
  "status": 409,
  "detail": "Diese Location hat noch kein Auszahlungskonto verbunden.",
  "traceId": "0HNOK3A31C71Y"
}

connect-not-enabled

409. Wird von POST /api/operator/venue/payouts/onboarding-link zurückgegeben, wenn Stripe die Erstellung des Connect-Standard-Kontos der Location ablehnt, weil das eigene Stripe-Konto der Plattform sich noch nicht für Connect angemeldet hat – nichts, was der Betreiber der Location getan hat, und nichts, was er beheben kann. Auch ein erneuter Versuch hilft nicht: Die Operator-API erzeugt pro Versuch einen neuen Idempotenzschlüssel, aber Stripe lehnt dieselbe zugrunde liegende Voraussetzung weiterhin ab, bis das Plattformkonto Connect aktiviert. Abhilfe: nichts auf Seiten der Location – das ist ein Konfigurationsproblem von BookDinePlay; wenden Sie sich an den Support.

{
  "type": "https://bookdineplay.com/docs/api/errors/connect-not-enabled",
  "title": "Connect not enabled",
  "status": 409,
  "detail": "Wir können derzeit noch keine Stripe-Konten verbinden. Das liegt an uns — bitte versuchen Sie es später erneut oder kontaktieren Sie den Support.",
  "traceId": "0HNOK3A31C721"
}

connect-rejected

409. Wird von derselben Onboarding-Link-Route zurückgegeben, wenn Stripe zwar akzeptiert, dass Connect selbst aktiviert ist, aber die eigenen Kontodaten dieser Location ablehnt – in der Praxis Land, Umsatzsteuer-ID oder die Form der Website-URL der Firma. Anders als connect-not-enabled kann der Betreiber hier direkt reagieren. Abhilfe: Firmenprofil unter Abrechnung → Firma prüfen (Land, Umsatzsteuer-ID, Website), korrigieren und erneut auf Verbinden klicken.

{
  "type": "https://bookdineplay.com/docs/api/errors/connect-rejected",
  "title": "Connect rejected",
  "status": 409,
  "detail": "Unser Zahlungsdienstleister konnte diese Location-Daten nicht akzeptieren. Bitte prüfen Sie Land, Umsatzsteuer-Identifikationsnummer und Website der Firma und versuchen Sie es erneut.",
  "traceId": "0HNOK3A31C722"
}

Gutschein-Probleme

Jede Route, die einen Gutscheincode annimmt, antwortet mit diesen: die Gutschein-Routen, die Tab-, Anzahlungs- und Ticketzahlungen mit voucherCode und die Gutscheinseiten der Konsole. Ein Problem enthält nie den Code. Einige erreichen nur die Konsole; sie stehen hier, damit jede type-URL irgendwo landet.

voucher-not-found

404. Der Code führt zu keinem Gutschein, der hier verwendbar ist: vertippt, unbekannt, ein nie bezahlter Kauf oder ein Gutschein einer anderen Location. Alle diese Fälle geben absichtlich dieselbe Antwort, damit Codes nicht durchprobiert werden können. Abhilfe: Bitten Sie den Gast, den Code zu prüfen. Die SDKs fangen einen Tippfehler vor dem Senden ab, weil das letzte Zeichen ein Prüfzeichen ist.

voucher-not-redeemable

409. Den Gutschein gibt es, aber er kann nichts mehr bezahlen. reason nennt den Grund: Expired, Voided oder UsedUp, und detail sagt es in einem Satz. Abhilfe: detail anzeigen; der Gast bezahlt anders.

{
  "type": "https://bookdineplay.com/docs/api/errors/voucher-not-redeemable",
  "title": "Voucher not redeemable",
  "status": 409,
  "detail": "Dieser Gutschein ist abgelaufen.",
  "reason": "Expired",
  "traceId": "0HNOK3A31C723"
}

voucher-insufficient-balance

409. Vom Gutschein wurde mehr verlangt, als er verfügbar hat; Wert, den eine laufende Zahlung reserviert hält, gilt als weg. Am Tisch hat das Personal mehr verlangt, als ein Betragsgutschein noch hat. Online nehmen die Zahlungen nur, was der Gutschein hat, und belasten den Rest der Karte – hier heißt es also, dass alles Übrige von einer anderen laufenden Zahlung reserviert ist. Abhilfe: einen kleineren Betrag einlösen oder es erneut versuchen, sobald die andere Zahlung abgeschlossen oder verfallen ist.

voucher-not-applicable

409. Diese Gutscheinart kann das nicht bezahlen, oder ihre Währung ist nicht die der Location. Anzahlung und Tickets nehmen nur Betragsgutscheine; Prozent- und Artikelgutscheine bezahlen eine Rechnung. Abhilfe: Sagen Sie dem Gast, dass der Gutschein für den Tisch gedacht ist, und machen Sie ohne ihn weiter.

voucher-busy

409. Eine andere Zahlung oder Kasse hat denselben Gutschein im selben Moment verwendet. Es wurde nichts abgebucht. Abhilfe: dieselbe Anfrage nach einem Moment wiederholen.

voucher-validity-not-set

409. Die Location hat noch nicht festgelegt, wie lange ihre Gutscheine gelten, und kann deshalb noch keine ausgeben oder verkaufen. Abhilfe: auf Ihrer Seite nichts; die Location legt die Gültigkeit in den Gutschein-Einstellungen der Konsole fest.

voucher-validity-too-short

400. Ein bezahlter Gutschein muss mindestens ein Jahr ab seiner Ausgabe gelten. Die Gültigkeitsregel der Location, ein von Hand ausgegebener Gutschein oder eine Änderung des Ablaufdatums würde ihm weniger geben. Abhilfe: Die Location wählt eine längere Gültigkeit.

voucher-sale-not-available

409. Gutscheine lassen sich bei dieser Location gerade nicht online kaufen: Der Online-Verkauf ist aus, das Produkt wird nicht online verkauft, Zahlungen sind ausgeschaltet, oder das Auszahlungskonto kann kein Geld annehmen. Die Angebote melden dasselbe schon vorher in onlineSaleAvailable. Abhilfe: den „nicht verfügbar“-Zustand der Angebote zeigen.

voucher-not-refundable

409. Nur Konsole: Ein Gutscheinverkauf lässt sich nur erstatten, solange der Gutschein unbenutzt ist, online verkauft wurde und nicht von einer laufenden Zahlung reserviert ist. Abhilfe: Einen benutzten Gutschein direkt mit dem Gast klären.

voucher-refund-failed

502. Nur Konsole: Stripe hat die Erstattung eines Gutscheinverkaufs nicht abgeschlossen. Es wurde nichts geändert, und der Gutschein ist weiter gültig. Abhilfe: erneut versuchen oder direkt in Stripe erstatten.

voucher-undo-not-allowed

409. Nur Konsole: Eine Einlösung am Tisch lässt sich einmal rückgängig machen, und außerhalb des Rückgängig-Fensters nur mit einer Begründung des Personals. Online-Einlösungen werden stattdessen über die Erstattung der Zahlung rückgängig gemacht.

voucher-hold-live

409. Nur Konsole: Eine laufende Zahlung hält Wert auf diesem Gutschein reserviert, deshalb lässt er sich gerade nicht entwerten und sein Verkauf nicht erstatten. Abhilfe: erneut versuchen, sobald der Gast die Zahlung abgeschlossen oder abgebrochen hat.

Plattform-Admin-Probleme

Wird nur von der Plattform-Admin-Oberfläche unter /api/admin/** beantwortet – nicht Teil der öffentlichen Widget-/SDK-API, aber Teil derselben Referenz (aus demselben Grund, aus dem billing-managed-by-stripe oben hier dokumentiert ist).

operator-already-exists

409. Wird von POST /api/admin/tenants/{id}/operators zurückgegeben, wenn das Auth0-Subject oder die E-Mail-Adresse aus der Anfrage bereits zu einer anderen Operator-Zeile gehört. Ein Subject muss sich auf genau einen Operator auflösen (ein Duplikat hat einen Plattform-Administrator schon einmal den Zugang zur eigenen Konsole gekostet), und zwei Zeilen mit derselben E-Mail-Adresse sind dieselbe Mehrdeutigkeit aus der anderen Richtung. Abhilfe: die vorhandene Zeile weiterverwenden statt eine zweite anzulegen, oder ein anderes Subject/eine andere E-Mail-Adresse angeben, falls es sich wirklich um eine andere Person handelt.

{
  "type": "https://bookdineplay.com/docs/api/errors/operator-already-exists",
  "title": "Operator already exists",
  "status": 409,
  "detail": "Für dieses Auth0-Subject existiert bereits ein Operator.",
  "traceId": "0HNOK3A31C724"
}

not-a-demo-venue

403. Wird von POST /api/admin/demo-venues/{venueSlug}/reset zurückgegeben, wenn venueSlug keine der eigenen Demo-Locations von BookDinePlay benennt. Dieser Endpunkt löscht die Transaktionsdaten einer Location — Reservierungen, Tischsitzungen, Event-Anmeldungen und -Tickets, Gast-Konversationen und QR-Tokens — für Release-Validierungsläufe; alles andere wird von vornherein abgelehnt, damit er niemals die Daten eines echten Kunden erreichen kann. 403, nicht 404: der Slug kann durchaus eine echte Location benennen, und genau das ist der Punkt — dieser Endpunkt wirkt niemals auf sie.

{
  "type": "https://bookdineplay.com/docs/api/errors/not-a-demo-venue",
  "title": "Not a demo venue",
  "status": 403,
  "detail": "Über diesen Endpunkt können nur die Transaktionsdaten einer Demo-Location zurückgesetzt werden.",
  "traceId": "0HNOK3A31C724"
}

Probleme ohne Reason-Code

Diese tragen den allgemeinen RFC-9110-type; detail sagt, was passiert ist.

Nächste Schritte

• Authentifizierung – dieselben Ablehnungen aus Sicht des Schlüssels.
• API-Referenz – das Format des Problem-Bodys.
• Events – woher die Anmelde-, Checkout- und Erstattungsprobleme kommen.