> ## Documentation Index
> Fetch the complete documentation index at: https://developers.safarapi.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Sandbox
> Test SafarAPI with realistic data, no production effects
The sandbox is a fully production‑like environment running on the **same infrastructure** as production. Isolation is enforced at the database level: sandbox data lives in a **dedicated PostgreSQL schema** (`safariat_sandbox`), never mixed with production rows. `sk_test_*` keys route to the sandbox schema; `sk_live_*` keys route to production. The routing is a hard SQL boundary, not an application filter.
## How to get a sandbox key
Self‑service signup at [console.safarapi.com/signup](https://console.safarapi.com/signup). Magic link in your inbox within 30 seconds. Sandbox key visible once on the activation page — copy it then.
## What's in the sandbox
The sandbox mirrors the **production catalogue**: every adventure, agency, rate pack, and category visible to your `sk_live_*` key has a clone in the sandbox schema. The clone refreshes every Sunday at 03:00 UTC, so a new prod adventure shows up in your sandbox within the week.
| Resource | Source | Notes |
| ---------- | ------------------------- | -------------------------------------------------------------------------- |
| Adventures | Full production catalogue | Slugs suffixed `-sandbox` (cosmetic — helps you spot sandbox URLs in logs) |
| Rate packs | Full clone | Same prices and schedules as prod |
| Agencies | Full clone | Real agency names — your bank can show realistic partner data to QA |
| Categories | Full clone | desert, mountain, beach, culture, urban, etc. |
The Sunday refresh **never touches your sandbox bookings, quotes, or idempotency keys**. Your integration history stays intact across weeks.
## Pre-defined test travellers
The sandbox simulates real payment behaviours based on the **traveler email** you pass on `POST /bookings`:
| Email | Behaviour |
| --------------------------------------- | ------------------------------------------------------------------- |
| `test.success@bank.example` | Booking confirmed, voucher generated, email sent to sandbox sink |
| `test.cancellation@bank.example` | Booking confirmed, but cancellation API behaves with tier 1 refund |
| `test.insufficient_credit@bank.example` | `POST /bookings` returns `403 partner.credit.limit.exceeded` |
| `test.amount_mismatch@bank.example` | `POST /bookings` returns `422 payment.amount.mismatch` |
| `test.duplicate_ref@bank.example` | Second `POST /bookings` with same `partner_reference` returns `409` |
Any other email behaves like `test.success@bank.example`. Real email addresses are accepted but **no email is ever sent** in sandbox — all messages route to `sandbox-sink@safariat.ma`.
## Rate limits in sandbox
100 requests per minute per key. Sufficient for integration testing; if you need more for load testing, [contact us](mailto:hello@safarapi.com).
## Resetting your sandbox
The console exposes a **"Reset sandbox data"** button under Settings. Clicking it erases all bookings, quotes, and idempotency keys created with your test key in the last 30 days. The cloned catalogue (adventures, rate packs, agencies) remains untouched.
## What's different from production
| Aspect | Sandbox | Production |
| ------------------- | ------------------------------------------------------------------ | ------------------------ |
| Settlement invoices | Not generated | Generated monthly |
| Email to traveller | Sink ([sandbox-sink@safariat.ma](mailto:sandbox-sink@safariat.ma)) | Real recipient |
| Webhook payload | `event.test = true` | `event.test = false` |
| Rate limit | 100 req/min | 600 req/min (negotiable) |
| Credit limit | 50 000 MAD default | Per‑contract value |
| Pricing rules | Zero margin (passthrough) | Your negotiated rules |
## Isolation guarantees (for your compliance team)
Sandbox isolation is enforced **at the PostgreSQL level**, not at the application level:
* **Dedicated schema** — every sandbox table lives in `safariat_sandbox.*`, structurally identical to but separate from `safariat.*` (production).
* **Per‑request routing** — each authenticated request opens its database connection with `SET search_path TO , public`. A `sk_test_*` key forces `search_path = safariat_sandbox, public`; a `sk_live_*` key forces `safariat, public`. The mapping is set by an authentication filter that runs before any business logic touches the database.
* **Connection hygiene** — every connection returning to the pool has its `search_path` reset to the production default, eliminating cross‑request leak risk. Validated by an automated test that performs 100 sandbox checkouts followed by a live checkout against a real PostgreSQL instance.
* **Audit trail** — the `partner_api_audit_log` table records every request with its `environment` tag (`LIVE` or `TEST`), preserved indefinitely.
This satisfies the "where is my test data stored?" question for Bank Al‑Maghrib externalisation reviews. See [`security/overview`](../security/overview) for the broader compliance posture.
## Time‑limited sandbox keys
A sandbox key is **active for 30 days of inactivity**. If you don't make any request for 30 days, the key is auto‑disabled. Re‑activate it with a single click from the console.
There's no calendar expiration — as long as you keep using it, your sandbox key works indefinitely.