Certification

Before production credentials are issued, you show that your integration handles the booking lifecycle correctly on the sandbox. You run the test cases below with your own code, send us the evidence, and we check it against the sandbox's records. You do not need our source code, and we never ask for your API key or webhook secret.

How it works

1. You run the cases on the sandbox with your production-ready integration (not hand-made HTTP calls), against the venues granted to you.
2. You send the evidence package (below) to [email protected].
3. We check it. We look up each request_id in the sandbox's records and confirm the outcome matches. We also run our own contract checks against the sandbox with a VenueSetu key.
4. Joint session, if needed. For the webhook and reconciliation cases we may ask for a short screen-share session, so that venue staff can make a change on our side while you show how your integration reacts.
5. Result in writing. Either every case passes, or we list each failing case with the HTTP exchange that failed (never a stack trace). Fix and resend only the failed cases.
6. Sign-off. The VenueSetu platform team confirms certification in writing. Then production onboarding starts.

Test cases

#	Case	What you do	Pass when
C1	Authentication	Call GET /partner/venues with your key; make one call with no key.	200 with your venues; the keyless call gets 401 and your code reports a credential problem, not a retryable error.
C2	Discovery	List venues, get one, list its resources.	Ids come from the API, not hard-coded; resource_id is copied verbatim.
C3	Availability	Read a day's availability for a granted venue.	The date is the venue's local day; times are shown to the customer in the venue's time zone; is_available is treated as a hint.
C4	Book	Hold an available slot, take a (test) payment, confirm before hold_expiry_at, then read the booking.	Hold 201, confirm 201, GET /bookings/{id} shows BOOKED. Your customer sees the booking only after confirm succeeded.
C5	Abandoned checkout	Hold a slot, abandon checkout, release the hold.	POST /partner/holds/{id}/cancel 200; the slot is available again.
C6	Hold expired	Hold a slot and let it expire, then try to confirm.	409 HOLD_EXPIRED; your customer is not shown a booking and the payment goes to your refund or rebook path.
C7	Slot taken	Try to hold a slot that is already held or booked.	409 SLOT_NOT_AVAILABLE; you offer another slot and do not retry the same hold.
C8	Safe retries	Repeat a hold and a confirm with the same idempotency_key; then make a new hold with a new key.	Same hold_id and booking_id come back; no second hold or booking exists. The key is stored with your local operation, not generated per HTTP attempt.
C9	Cancel and refund	Cancel a booking; if you use refunds, refund one; repeat each with the same key.	200 each time; the booking reads CANCELLED / REFUNDED.
C10	Rate limit	Show how your client handles 429.	It waits for Retry-After before retrying. A code excerpt is enough; you do not need to trigger 429.
C11	Webhook receiver	Subscribe a public https endpoint; make and cancel a booking.	You receive booking_created and booking_cancelled, verify X-CBMS-Signature over {timestamp}.{rawBody}, reject a tampered body and a timestamp more than 300 seconds old, and ignore a repeated event_id.
C12	Reconciliation	Show your scheduled reconciliation against GET /bookings. In a joint session, venue staff cancel one of your bookings on our side.	Your records show the cancellation, from the webhook or from reconciliation, and your customer is told.
C13	Confirm fails after payment	Reproduce a confirm that fails after payment (C6 is one way).	Not shown as booked; not retried with the same body; the payment enters your refund or rebook flow.

Evidence package

Send one document (PDF, spreadsheet or Markdown) with:

• For each case: the case number, the UTC time, the request_id of each call (from the X-Request-Id response header), the HTTP status, and the hold or booking ids involved.
• For C3, C4, C6 and C13: a screenshot or short recording of what your customer sees.
• For C11: your receiver's log lines for each delivery (event_id, delivery_id, X-Delivery-Attempt, signature verified yes or no), including the rejected tampered and stale cases. You can test your verifier first with GET /partner/webhooks/{partnerId}/signature-sample (see Webhooks).
• For C10 and C12: a short description or code excerpt, and the reconciliation schedule you run.

Never include your API key, your webhook secret_key, or real customer data. Use test names and numbers.

After you pass

See Production onboarding.