Skip to main content

The sandbox

A seeded, resettable copy of the sample world, owned by your account and reachable only with a sandbox credential.

What it contains

The same people the product demo is built around, planted as real rows in the real database under a synthetic tenant address ending in @sandbox.invalid.

Sam Rivera, an applicant mid-search
A board with cards in every column, companies, contacts, logged interactions, interviews, a resume and enough history for the insights to have something to say.
Jordan Lee’s career centre, an organization
Staff, cohorts, an applicant roster, boards applicants have shared with it, coach notes and audit events.

What behaves differently

  • Billing is simulated. A checkout or portal session answers with a URL inside this documentation rather than opening Stripe.
  • No email is ever sent. An invitation exists only as the link the answer hands back.
  • Nothing is shared between accounts. A sandbox is seeded per account, not per deployment.

Resetting it

A reset deletes everything the sandbox tenant owns and plants the sample world again, so a test can start from a shape it knows. GET /sandbox reports when the next reset is allowed; asking sooner is refused with rate_limited.

Read the sandbox, then reset it
curl -s https://www.jobapplicationtracking.com/api/v1/sandbox \
  -H "Authorization: Bearer $JAT_KEY"

curl -s -X POST https://www.jobapplicationtracking.com/api/v1/sandbox/reset \
  -H "Authorization: Bearer $JAT_KEY"

Both need the sandbox:manage scope, which only the full-access preset grants — a reset is destructive, and a key handed to a third party should not be able to do it by accident.