Appearance
Sandbox
The sandbox is a full CBMS deployment with its own database, Redis, keys, and webhook secrets. Same routes and rules as production. It is not a mock.
Use it for all integration work until you are certified.
Host
https://stage.cbms.venuesetu.comAPI prefix: https://stage.cbms.venuesetu.com/api/v1
Confirm you are on sandbox with an unauthenticated request:
http
GET /healthjson
{ "status": "ok", "sandbox": true, "timestamp": "…" }Production reports "sandbox": false. Never mix keys across the two hosts.
Credentials and venues
When we onboard you, you get your own partner identity on the sandbox host and a sandbox API key for it. Put the key in x-api-key on every API call. Your holds, bookings, waitlist entries and webhook subscriptions belong to that identity: no other partner can read, change or cancel them. Other channels granted the same venue only learn that a slot changed, without your customer's details (see Webhooks).
We then grant that identity the specific venues you will integrate: each venue you will sell gets a sandbox copy on the sandbox host, and we grant you that copy. We may also grant the shared test venues below, for throwaway testing.
GET /partner/venues lists exactly the venues you are granted — no more. Until a grant lands, it is an empty list. Discover each venue's venue_id and resource_ids from the API; do not assume the ids in the table below are the only ones you will see.
Venues on the sandbox host, including sandbox copies of real venues, are sandbox records. Nothing you hold, book or cancel there reaches the venue's live calendar or its customers.
Shared test venues
In addition to the venues you are onboarding for, the sandbox has two deterministic test venues. If they are granted to you, you can discover them through the API; they are listed here so your tests can assert them.
| Value | |
|---|---|
| Venue A | a0000000-0000-4000-8000-000000000001 — Sandbox Venue A, badminton |
| Courts at A | badminton-court-1, badminton-court-2 |
| Venue B | a0000000-0000-4000-8000-000000000002 — Sandbox Venue B, box cricket |
| Court at B | box-cricket-court-1 |
| Package at A | a0000000-0000-4000-8000-000000000003 — 5-session pack |
Prefer discovery over hard-coding, the same way you will in production. The ids above are stable across re-seeds.
Slots are a rolling ~3-week AVAILABLE grid. Pick a future date from GET /slots/availability.
Exercise the booking flow
Follow Booking flow against this host. A minimal loop:
- List venues and resources.
- Query availability for one of your granted venues (for example Sandbox Venue A with
badminton-court-1) for a date 1–14 days ahead. - Hold an
is_available: trueslot with a freshidempotency_key. - Confirm with a fake
payment_reference(sandbox does not charge a card). - Cancel or refund with another fresh key.
- Retry step 3 or 5 with the same key you used the first time — you should see the original result.
Webhooks
Subscribe with POST /api/v1/partner/webhooks to a URL you control (your laptop via a public HTTPS tunnel, or a hosted receiver). The endpoint rules are the same as production: https, on a public address, otherwise 400 INVALID_WEBHOOK_ENDPOINT. Signing is identical to production. See Webhooks.
Deliveries are produced by real sandbox actions you take. There is no “inject event” endpoint.
Sandbox and production differences
The sandbox runs our newest release. Production is updated less often, so for a while some behaviour exists on the sandbox before it reaches production. Build for the sandbox behaviour: each item below is also coming to production, and your production access is enabled only on a production release that includes it.
The sandbox and production currently run the same partner-visible behaviour.
The changelog marks each change with where it is live. Everything else on this site applies to both.
Limits and housekeeping
- Same rate limit as production: 60 requests / 60 seconds per key.
- The sandbox is shared: other partners and venue staff use the same venues and slots. Do not depend on a slot remaining free after you looked at it — hold is the reservation.
- If the slot grid is exhausted or the dataset is messy, email [email protected] and the platform team will clean it up. That is an operator action, not a partner API.
Do not point production traffic, production keys, or a live customer checkout at this host.
