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.
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.