Skip to main content
A sk_test_ key is served entirely from a small fixed dataset. Reads return realistic sample data; writes report success and change nothing. It’s the same code path as live — same validation, same response shapes, same rate limits — with a different data source.
Nothing in test mode touches your real data. You cannot see, create, modify or delete a real assessment, candidate or submission with a test key. Build freely.

​
The sandbox is stateless

This is the one thing that surprises people:
Writes are simulated. A POST returns a realistic created object with a fixed id, but nothing persists — a GET afterwards returns the unchanged sample data. Don’t write a test that creates something and then expects to read it back.
The upside is that responses are byte-stable. The same request always returns the same bytes (apart from request_id), so you can snapshot-test your integration against us.

​
Sample data

The sandbox is one small, internally consistent organization: three challenges, two assessments, four invitations across different statuses, and three submissions — one fully evaluated with a complete report, one in progress, one submitted but not yet graded. These ids resolve in test mode and are safe to hard-code:

​
Reproducing errors

Most failures happen naturally: send an invalid body for a 400, use a read-only key on a write for a 403, hammer an endpoint for a 429, or revoke the already-evaluated invitation above for a 400. Two cases can’t be triggered that way, so the sandbox recognises these values:

​
What test mode does not do

Creating an invitation returns a realistic invitation_url, but no email is sent and the token is not redeemable. To exercise the candidate side, use a live key on a real assessment.
Reports come from fixed sample data rather than a real evaluation. The evaluated submission always returns the same report.
workspace_archive_url is null for every sandbox submission — there’s no real archive to sign. Treat null as “not available”, which is also what live returns before a candidate submits.
Test keys draw on the same hourly quotas as live keys, deliberately, so you can see and handle a real 429 with its Retry-After header before you go to production.

​
Using the playground

The interactive playground in the API reference sends real requests. Use a test key there. Requests are proxied server-side rather than sent from your browser, so a key pasted into the playground travels through Mintlify’s infrastructure — fine for a sandbox credential, not something to do with a live key.