Sandbox & test keys
Ask the platform administrator for a test key (wk_test_…) to build and validate your integration without creating real bookings.
| Live key | Test key | |
|---|---|---|
| Search / pricing | Real pricing rules | Same |
POST /bookings |
Creates a booking, charged to your tenant | Returns a simulated booking (livemode: false, PNR starts TEST); nothing is stored |
GET /bookings |
Your bookings | Always empty |
| Webhooks | Delivered | Not sent |
| Rate limits, scopes, signing, IP rules | Enforced | Enforced identically |
A simulated booking response looks like a real one so your code path is identical:
{ "data": { "id": "bkg_483920", "pnr": "TEST3F9A", "type": "flight", "status": "Upcoming", "amount": 6048, "currency": "INR", "livemode": false } }
Because test bookings are not stored, you cannot fetch or cancel them afterwards.
Simulated inventory (all keys)
Until a supplier is connected, search inventory is generated from your query for every key, live or test. Times, fares and hotel/car names are plausible but are not real availability. Offers are deterministic for the same query and remain valid for 15 minutes via their offerToken. When a supplier connection is enabled, the response shapes stay the same and simulated becomes false.