> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flightlinehq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sandbox

> Build and test the full review loop instantly, for free, with no real analysis.

Sandbox is an in-app test mode that lets you build and exercise the entire
integration (create a review, poll its status, fetch its report, and receive
a webhook) **without running real analysis**. Sandbox reviews return canned
results instantly, cost nothing, and never enter the real pipeline.

Use sandbox to wire up and verify your integration end to end before you point
a live key at real loan packages.

## Sandbox API keys

A sandbox key is a normal Flightline organization API key that we provision
with a `sandbox` claim. You authenticate with it exactly like a live key
(`Authorization: Bearer <key>`), and every request behaves identically on the
wire; only the processing differs.

Ask us to issue you a sandbox key for your organization. Live and sandbox keys
are separate credentials; a live key never returns canned data, and a sandbox
key never runs real analysis.

## What's different in sandbox

When you call the API with a sandbox key:

* **`POST /reviews`** ingests your documents over the real upload path (so you
  exercise the genuine multipart / signed-URL flow), then returns immediately
  with `status: "completed"` and `report_available: true`. The review never
  runs the real (slow, paid) analysis pipeline.
* **`GET /reviews/{review_id}`** and **`GET /reviews/{review_id}/report`** both
  carry `"sandbox": true` so your code can tell it is in test mode.
* **`GET /reviews/{review_id}/report`** returns a deterministic, obviously
  canned report (see below) instantly; no waiting, no polling loop required.
* A real **`review.completed` webhook** fires to the endpoints you registered
  **with your sandbox key**, so you can test your webhook receiver (signature
  verification, payload parsing) exactly as in production.

<Note>
  Webhook endpoints belong to the mode of the key that registered them. A
  sandbox key registers, lists, and deletes sandbox endpoints; a live key does
  the same for live ones, and neither can see the other's. Sandbox reviews
  therefore never deliver to your production receiver, and real reviews never
  deliver to a test one — so register your test receiver with your sandbox key.
</Note>

Everything else (authentication, rate limits, error shapes, org isolation,
the audit trail) behaves exactly as it does live.

## The canned report

Every sandbox report returns the same fixed set of illustrative sample issues.
They are **not** produced by analysis and do not correspond to your uploaded
documents:

| Code         | Severity | Title                                |
| ------------ | -------- | ------------------------------------ |
| `SAMPLE-001` | `high`   | Sample: APR tolerance exceeded       |
| `SAMPLE-002` | `medium` | Sample: Missing income documentation |
| `SAMPLE-003` | `low`    | Sample: Minor data inconsistency     |

The `outcome` is always `issues_found` and the summary counts match the issues
above. Each issue's `summary` text states plainly that it is sample sandbox
data. Treat the `SAMPLE-*` codes as illustrative only; real reviews carry real
rule codes (for example `APR-003`).

<Note>
  Sandbox reviews are marked internally and never enter the analysis pipeline, so
  they incur no cost and never appear alongside your production results.
</Note>