Skip to content

Sandbox & testing

There is no separate test environment to learn. A sandbox account is a real account on the real API whose fills are matched by the platform’s own engine instead of being dispatched to an exchange. The order path, the WebSocket frames, the reports — all identical. Only the counterparty changes.

That is the point: an integration proven against a sandbox account is proven against the code that will carry real money.

One call provisions a paper account for your credential, seeds it with a balance, and (by default) opens a demo position so your first read has something in it:

Terminal window
curl -s https://api.troncharts.xyz/api/v1/sandbox/paper-account \
-H "authorization: Bearer $TOKEN" \
-H "x-tenant-slug: $TC_TENANT_SLUG" \
-H 'content-type: application/json' \
-d '{}'

The account is linked into your credential’s ownership scope, so it appears in GET /api/v1/accounts and its state and positions are readable immediately — no operator step, no ticket.

See Paper accounts for the fields and the response.

Be clear-eyed about the boundary, because it decides what you still have to test in production:

Exercised faithfully Not exercised
Order compose, sign, dispatch, and lifecycle The venue’s own matching and queue position
Every /ws/risk frame, including fills and terminal states Real slippage and partial-fill patterns under stress
Margin, balance, and risk recomputation Exchange outages and venue-side rejections
Reports, analytics, and reconciliation reads Actual withdrawal and custody paths

A sandbox fill is matched against a firm-canonical mark, not against a live order book. Your execution logic is proven; your assumptions about fill quality are not.

Sandbox provisioning is enabled per deployment. Where it is off, the endpoint answers 404 — deliberately indistinguishable from not existing, so a probe learns nothing. If you get a 404 and expect otherwise, ask the operator of your deployment rather than assuming the path is wrong.