Skip to content

Sandbox

The sandbox venue, its test data and how it resets every night.

The sandbox gives you a made-up venue of your own, qa-sandbox Lounge, on Boozie's test environment. Build and test against it without touching a real venue or a real guest.

  • Base URL: https://api-dev-799b.up.railway.app/public/v1
  • Keys: ask for one with the form on the portal or POST /sandbox/keys. It arrives by email, never in the answer. The endpoint needs no key and accepts calls from a browser on any page (CORS), so you can put the form in your own docs.

Sandbox keys#

Formatbz_test_…, sent as Authorization: Bearer <key>
VenueYour own sandbox venue only; its id is in the email. Any other venueId is 404.
ScopesAll of them, including customers:pii (every person in the sandbox is fake) and hosts:read
HostBound to your venue's host, so /hosts/me, /hosts/me/customers and /hosts/me/report work
Rate limit60 requests a minute, bursts of 120
Expiry30 days after it is sent

Limits on asking for keys:

LimitWhat happens over it
3 a day per email addressThe answer is still 202, but nothing is sent. The day counts from the address's first request.
10 a day per IP address429 rate_limited, with Retry-After in seconds.
200 a day in all429 rate_limited, with Retry-After. Everyone shares this one.
3 active keys per addressNo new key: you get an email saying when your keys expire instead. A slot frees up when one expires.
200 sandbox venues in allA new address gets an email saying the sandbox is full, and no key. Venues free up as their keys expire.

The answer is the same 202 whether or not an email goes out, so it says nothing about the address. The answer's venueId is always 0 (deprecated): your venue is made in the background with your first key, and its id comes in the email. A bad address or a name over 60 characters gets 422 invalid_request. 404 sandbox.unavailable means this environment has no sandbox: Boozie turns it on per environment, and never on production. 503 sandbox.not_ready means the sandbox is on but can't make venues yet, so try again later.

A sandbox key holds every scope, so your code may pass on the sandbox and fail on a real venue whose key has fewer. Before going live, test with a key limited to the scopes you'll ask for: a venue owner can make one in the back office.

What's in it#

CountrySingapore: SGD, +65 phones, times in +08:00
PlanPremium, so bookings, the guest list and analytics all work
BookingsConfirmed by hand. A pending booking expires after 24 hours (not 30 minutes as at real venues), so you can try confirming and rejecting.
Tables6: T1–T4 (standard, seat 6), B1 (booth, seats 8), V1 (VIP, seats 12, at least 4)
HoursEvery night 21:00–03:00
SessionsEvery night 21:00–23:59 and 00:00–03:00. The 00:00 session belongs to the night before.
Guest listEvery night, cut-off 23:30, up to 60 people
Customers8 fake accounts, Ava Sandbox to Hiro Sandbox, with qa-sandbox-…@example.com emails and +65555001xx phones. Four are in the host's book.
Contacts2 guests without an account: Ivy Sandbox and Jun Sandbox
BookingsFor the coming 14 nights, 2 or 3 a night in every status. For the last 7 nights, arrivals, seated guests and a no-show.
Guest list entriesJoined names on coming nights; arrivals and a no-show on past ones
Reviews4, rated 3 to 5, one with the venue's reply

The nightly reset#

Every day at 06:30 Singapore time (UTC+8) every sandbox venue is wiped and seeded again.

  • Removed: every booking, guest-list entry, review and contact, including what you made through the API.
  • Seeded again: the bookings, contacts, guest list and reviews above, with new ids.
  • Kept: the venue and its id, its owner and host, the 8 fake customers, your keys and your webhook endpoints and their secrets.
  • Deleted: a venue whose address has no live sandbox key left (all expired or revoked) goes at the reset, and its webhook endpoints with it. Ask for a key again and you get a new venue, with a new id.
  • No webhook events are sent for the reset: old bookings disappear and new ones appear silently.

So don't hard-code ids. Look them up each time:

  • GET /venues/{venueId}/tables and /sessions;
  • GET /venues/{venueId}/bookings?from=…&to=…;
  • GET /venues/{venueId}/guest-list?date=YYYY-MM-DD;
  • GET /venues/{venueId}/reviews;
  • GET /hosts/me/customers.

Your venue is your own#

Each email address gets a sandbox venue of its own, and every key sent to that address works on it:

  • Nobody else sees your bookings, guest list or webhook endpoints, and your endpoints get your venue's events only.
  • Keys for the same address share its venue, so a teammate needs their own address for a venue of their own.
  • The 8 fake customers are the same in every sandbox venue, but each venue has its own bookings, guest list and reviews of them.
  • Use made-up people only. Never put a real person's name, phone or email in the sandbox.

Next: Changelog