Two-phase booking
Availability is a hint. POST /bookings/hold reserves the slot. POST /bookings/confirm books it. There is no one-shot book call.
Hold a slot, collect payment on your side, then confirm. Start in the sandbox — production comes after certification.
Work against sandbox until you are certified.
x-api-key on every call.GET /api/v1/partner/venues — note a venue_id. An empty list means grants have not landed yet.GET /api/v1/partner/venues/{venueId}/resources — copy a resource_id verbatim.GET /api/v1/slots/availability — find a slot with is_available: true. That flag is not a reservation.POST /api/v1/bookings/hold — you get hold_id, hold_expiry_at, price_rupees.payment_reference.POST /api/v1/bookings/confirm before hold_expiry_at — you get booking_id.hold_created and booking_created.Base URL for all of the above:
https://stage.cbms.venuesetu.com/api/v1Every request (except this documentation and GET /health) sends:
x-api-key: <the opaque key issued to you>Next: Authentication · Sandbox · Booking flow · OpenAPI
Sandbox — start here
https://stage.cbms.venuesetu.comhttps://stage.cbms.venuesetu.com/api/v1GET /health → "sandbox": trueProduction — after certification
https://cbms.venuesetu.comhttps://cbms.venuesetu.com/api/v1GET /health → "sandbox": falseKeys are not interchangeable. A sandbox key does not work on production, and the reverse.
The sandbox runs our newest release and production follows later, so a few behaviours exist on the sandbox first. They are listed in Sandbox and production differences.
CBMS is the inventory source of truth for sports venues (courts, turfs, fields). Your application is a channel: you show availability, take the customer through checkout, and book through this API.
The guarantee you are integrating with:
For any slot, at most one hold is ACTIVE at a time. Concurrent attempts from any number of channels resolve to exactly one winner; everyone else gets
SLOT_NOT_AVAILABLE.