Environments

There are two fully separate environments. Every endpoint has the same path in both.

	Sandbox	Live
Base URL	https://transfers-sandbox.pathfndr.io	https://transfers.pathfndr.io
API key prefix	tp_test_	tp_live_
Reaches	Only the providers' test systems	Only the providers' production systems
Bookings	Test bookings: never a real ride, nothing is charged	Real, chargeable bookings

For example, search is https://transfers-sandbox.pathfndr.io/v1/search in the sandbox and https://transfers.pathfndr.io/v1/search in live.

A key only works in its own environment

A tp_test_ key sent to the live URL, or a tp_live_ key sent to the sandbox URL, answers 401 unauthorized:

401: sandbox key sent to the live URL

{
  "error": {
    "code": "unauthorized",
    "message": "Invalid API key",
    "provider": null,
    "request_id": "7c1d2e3f-4a5b-4c6d-8e9f-0a1b2c3d4e5f"
  }
}

If you get a 401 with a key you know is valid, check that the base URL matches the key prefix. Keep the pair together in your configuration (for example TP_BASE_URL and TP_API_KEY per environment).

Tokens do not cross environments

Offer tokens and booking tokens issued in one environment are refused by the other (422 invalid_offer_token or 422 invalid_booking_token). Search again in the right environment.

What the sandbox can reach

A sandbox key can only ever reach the providers' test systems, and a live key only their production systems. This is enforced for every request, so nothing you send with a tp_test_ key can create a real booking.

• Some providers have no test system and are only available with a live key. With a sandbox key they are not searched; naming one in providers lists it in meta.skipped_providers and in errors[] as provider_not_enabled, and the other endpoints answer 403 provider_not_enabled for it.
• Your onboarding sheet lists the providers enabled for your sandbox key.
• Sandbox prices, vehicles and availability are not representative of production.

See Testing in sandbox for test scenarios and rules.