Skip to main content

Testing in sandbox

The sandbox talks only to each provider's test system. Nothing you do there creates a real ride or a charge. There are no magic test values: the sandbox runs the same code as live, so you trigger each scenario with a real request, as described below.

Rules​

  • Cancel every test booking you create, straight after the test, and check with booking details that booking.status is cancelled (some providers first answer cancellation_pending).
  • Use obviously fake traveller data: Jane Doe, [email protected], +44 20 7946 0000.
  • Use pickup dates at least a few days ahead.
  • Test prices, vehicles and availability are not representative of production.
  • Some providers have no test system and are available with a live key only (Environments).

Test scenarios​

#ScenarioHow to trigger itExpected result
1Happy path, airportQuickstartcompleted booking, booking details, cancelled
2Point-to-point one way and round tripSearch with transfer_type: point_to_point (and trip_type: round_trip)outbound, return and possibly round_trip offers; book and cancel each leg
3HourlySearch with transfer_type: hourly, hours: 4Offers with package; some providers listed in meta.skipped_providers
4Idempotent replaySend the same book request twiceSecond response identical, header Idempotent-Replayed: true, one booking only
5Duplicate referenceRe-use an internal_reference with different travellers409 duplicate_booking
6Modified tokenChange one character of an offer_token and recheck422 invalid_offer_token
7Modified booking referenceChange supplier_reference.booking_id and call booking details422 invalid_booking_token
8Wrong environmentCall the live URL with your tp_test_ key401 unauthorized
9Missing keyOmit X-API-Key401 unauthorized with WWW-Authenticate
10ValidationSend hours: 25, or a point-to-point body without transfer_type422 validation_error with details
11Unsupported currencySearch with currency: "XYZ"422 unsupported_currency
12Provider not enabledName a provider that is not on your onboarding sheet in providersSearch: errors[] entry provider_not_enabled; recheck with it: 403
13Pending cancellationCancel with a provider that confirms later (provider-dependent)cancellation_pending, then cancelled in booking details
14Price changeRecheck an offer some time after the search (provider-dependent)price_changed: true and a new total_price; your UI asks the customer
15Rate limit handlingUnit-test your client against a 429 with Retry-AfterYour client waits and retries

Scenarios 13 and 14 depend on the provider's test system and cannot be forced. Make sure your code handles them, for example with a unit test that feeds it the documented response.

unknown book outcomes cannot be triggered on purpose either. Test your handling with the documented unknown response in a unit test.

Postman​

Import the collection and the sandbox environment, set api_key, and run the folders in order. The collection carries the offer token and booking reference from one call to the next.