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, jane.doe@example.com, +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

#	Scenario	How to trigger it	Expected result
1	Happy path, airport	Quickstart	completed booking, booking details, cancelled
2	Point-to-point one way and round trip	Search with transfer_type: point_to_point (and trip_type: round_trip)	outbound, return and possibly round_trip offers; book and cancel each leg
3	Hourly	Search with transfer_type: hourly, hours: 4	Offers with package; some providers listed in meta.skipped_providers
4	Idempotent replay	Send the same book request twice	Second response identical, header Idempotent-Replayed: true, one booking only
5	Duplicate reference	Re-use an internal_reference with different travellers	409 duplicate_booking
6	Modified token	Change one character of an offer_token and recheck	422 invalid_offer_token
7	Modified booking reference	Change supplier_reference.booking_id and call booking details	422 invalid_booking_token
8	Wrong environment	Call the live URL with your tp_test_ key	401 unauthorized
9	Missing key	Omit X-API-Key	401 unauthorized with WWW-Authenticate
10	Validation	Send hours: 25, or a point-to-point body without transfer_type	422 validation_error with details
11	Unsupported currency	Search with currency: "XYZ"	422 unsupported_currency
12	Provider not enabled	Name a provider that is not on your onboarding sheet in providers	Search: errors[] entry provider_not_enabled; recheck with it: 403
13	Pending cancellation	Cancel with a provider that confirms later (provider-dependent)	cancellation_pending, then cancelled in booking details
14	Price change	Recheck an offer some time after the search (provider-dependent)	price_changed: true and a new total_price; your UI asks the customer
15	Rate limit handling	Unit-test your client against a 429 with Retry-After	Your 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.