Skip to main content
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.

​
Before you start

  1. Sign in to the sandbox back office.
  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.
  5. Issue a test 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.
1

Open a run

Open the run with your 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.
2

Use your integration

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: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.
3

Read the results

Check progress at any time while the run is open.
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.
4

Close the run

Close the run to grade it.
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

​
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 covers what to do next.

​
Next steps

Use your results

Keep the result with your release, and fix what failed.

Requirements

Read each rule the run measures.