Skip to content

Changelog

What changed in v1, and how we change the API without breaking you.

How we change the API#

The API is versioned in its path: /public/v1. Within v1 we only make changes that don't break a well-behaved client:

  • new endpoints, new optional request fields and new fields in answers;
  • new enum values, new error codes and new webhook event types;
  • higher limits.

So: ignore fields you don't know, treat an unknown enum value or code as "other", and subscribe to webhook events by name. Anything that would break you (removing or renaming a field, changing a type, tightening a rule) waits for v2, which we'll announce well ahead and run alongside v1.

The spec's info.version and every webhook's apiVersion say which v1 you're talking to. Our CI compares each change to the spec against the last one and refuses breaking ones.

v1.0.0, phase 3: portal, sandbox, organisations and OAuth (November 2026)#

  • This developer portal, with the interactive reference and these guides.
  • Self-serve sandbox keys: POST /sandbox/keys emails a 30-day key to a sandbox venue of your own (one per email address), which resets every night. The answer's venueId is now always 0 and deprecated: the venue's id is in the email. See Sandbox.
  • Organisations: org keys that cover several venues of one group, and GET /venues to list what a key or token covers. See Organisations.
  • OAuth apps: authorization code with PKCE, rotating refresh tokens, and a consent screen where owners pick their venues. See OAuth apps.

v1.0.0, phase 2: bookings and webhooks (November 2026)#

  • Making bookings: POST /venues/{venueId}/bookings, for a customer or for a guest without a Boozie account (contact).
  • Availability: GET /venues/{venueId}/availability for a night's sessions and free tables.
  • Guest list writes: add names and mark them at the door.
  • Hosts: host-bound keys and /hosts/me, /hosts/me/customers and /hosts/me/report.
  • Webhooks: signed, retried, replayable events for bookings, the guest list and reviews. See Webhooks.

v1.0.0, phase 1: keys and reads (November 2026)#

  • Venue keys made in the back office, with scopes, test and live modes, rolling and revoking.
  • Read endpoints: the venue, tables, sessions, hours, menu, bookings, guest list, reviews, analytics and the public catalogue.
  • Booking status changes: confirm, reject, cancel and mark arrivals, with Idempotency-Key on every POST.
  • Problem details errors with stable codes, rate-limit headers and cursor paging.
  • The OpenAPI 3.1 spec at /public/v1/openapi.json.