> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Run a self-check
> Exercise your integration against the sandbox, which deliberately causes errors, and get a measured result for each rule.
Find out how your integration handles errors before your traders do. You open a run on the sandbox,
use your integration as you normally would, and the sandbox watches your requests and deliberately
throws a rate limit, a risk lock and a dropped stream at them. When you close the run, every rule
comes back as passed, failed or not exercised, with what was seen.
Self-checks are free: no payment setup, no meeting and nothing to send us. Use this page when your
integration is ready for its first full test, and again after every fix. By the end you have a
closed run with a result for each of the rules in [Requirements](/providers/requirements).
## Before you start
1. Sign in to the [sandbox back office](https://sandbox.trdrs.co/developer).
2. Create a **Partner API** key and a **Trading API** key under the same account. The Partner key
opens, reads and closes the run, and makes registrations; the Trading API key places orders and
opens account streams. A Partner key can't trade. A Venue key isn't measured by the run.
3. Use a dedicated test account. While a run is open, requests made with that account's keys can
receive deliberate errors.
4. [Set your venue's name and logo](/sandbox#set-your-venue-s-brand).
5. [Issue a test account](/sandbox#issue-your-first-evaluation-account) before you open the run.
Keep both keys on your server. Only requests with your own keys are part of your run; other
developers' keys and ordinary browser sessions aren't.
Open the run with your Partner key.
```bash theme={null}
curl --fail-with-body -X POST https://sandbox.trdrs.co/api/partner/conformance/runs \
-H "Authorization: Bearer $TRDRS_PARTNER_KEY"
```
The response is `201` with the `run`, listing every rule and how to exercise it. Save
`run.id` as `RUN_ID`. You can have one run open at a time, and it expires after two hours.
Requests that manage the run are never given deliberate errors.
Point your integration's own request and reconnect code at `https://sandbox.trdrs.co`. Don't use a
separate test client: it would hide the behavior the run is there to measure. During the run,
make sure your integration does all of this:
| Do this | The rule it exercises |
| - | - |
| Make at least five authenticated calls from your server with either key, three of them with the Partner key on `/api/partner/` routes | Keys stay on your server, and each key calls its own routes |
| Make two `POST /api/partner/connect/accounts` registrations without any trader credential | Registrations carry no credential |
| Place at least three orders that each carry a `clientOrderId`, and send one of them again with the same id. The repeat normally answers `409`, not a second fill | Every order has a `clientOrderId`, and a retry reuses it |
| Keep calling until you receive a `429`, then wait the stated three seconds before that key calls again. A retried order keeps its id | A `429` is waited out |
| Keep placing orders until one gets a `423`, then stop sending that order and stay quiet for at least ten seconds. You don't need to send it again | A `423` is a risk lock |
| Open `GET /api/account/stream?broker=paper&account=YOUR_ACCOUNT`. After its first full snapshot the sandbox drops it once; reconnect and take the new snapshot. `/api/market/stream` works too, when a feed is available | Streams recover from a snapshot |
Every deliberate error carries the headers `x-trdrs-conformance-fault` and
`x-trdrs-conformance-run`, and the rate limit states `Retry-After: 3`. They're ordinary HTTP
errors, so handle them the way you would in production. Orders outside a run behave normally.
Check progress at any time while the run is open.
```bash theme={null}
curl --fail-with-body "https://sandbox.trdrs.co/api/partner/conformance/runs/$RUN_ID" \
-H "Authorization: Bearer $TRDRS_PARTNER_KEY"
```
Each rule is `pass`, `fail` or `not_exercised`, with counts and an explanation. A run with no
traffic can't pass. One recorded failure fails its rule, and later successes don't erase it.
Close the run to grade it.
```bash theme={null}
curl --fail-with-body -X POST "https://sandbox.trdrs.co/api/partner/conformance/runs/$RUN_ID/close" \
-H "Authorization: Bearer $TRDRS_PARTNER_KEY"
```
The response records the ruleset version and the final result, and deliberate errors stop at
once. Every rule must be exercised and pass. A rate limit or dropped stream your client never
answered fails; a risk lock you left alone for ten seconds passes. Runs, what they observed and
any errors still due survive engine restarts, and an expired run can't pass.
## Errors
| Status | When | What to do |
| - | - | - |
| `401` | The key isn't a sandbox Partner key. | Use your sandbox Partner key. |
| `404` | The run doesn't exist, or belongs to another firm. | Check `RUN_ID`. |
| `409` | You called production, a run is already open, or this run is already closed. | Close the open run, or open a new one. |
## What a pass means
A pass measures how your client handled these API interactions. It can't see inside your client or
how your screen shows money, and it isn't approval of your business or a production listing.
[Use your results](/providers/submission) covers what to do next.
## Next steps
Keep the result with your release, and fix what failed.
Read each rule the run measures.