> ## 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. # Start a sandbox conformance run > Opens a free two-hour conformance run in the sandbox. During the run, trdrs watches the requests you make with your pre-registration and Trading API keys, and injects one rate limit, one risk lock and one dropped account and market stream for your client to handle. You can have one run open at a time. Required key: pre-registration key, in the sandbox. ## OpenAPI ````yaml /api/openapi.json post /api/pre-registration/conformance/runs openapi: 3.1.0 info: title: trdrs Engine API version: 1.1.0 description: >- ## API Reference Every route the trdrs engine serves, with what to send and what comes back. It covers market data and news, trading and account state for a trader's own software, the Connect API a Connect app's backend calls and the Connect dashboard's routes, Connect pre-registration, the statements that carry a Connect account between environments, the venue routes a prop firm or brokerage runs its accounts through, and a trader's own challenges. Start with the Quickstart for your first call. The API standards hold the rules every route shares: keys, errors, rate limits, idempotency, paging and streaming. servers: - url: https://app.trdrs.co description: Production - url: / description: This engine security: [] tags: - name: Venue platform preview description: >- Run your venue: its providers, instruments, conditions, groups, routes, stages, venue rules, keys, accounts, usage, balance receipts and webhooks. These routes are in preview. They are served on the sandbox to every venue, and production access is arranged when a venue qualifies. Every route here under `/api/venues/` takes a Venue key. The back office reaches the same routes under `/api/back-office/` with a verified owner’s session, because the Venue key stays on your server, and both run the same checks. The team’s routes under `/api/organizations` serve the back office and the Connect dashboard alike, since one organization can run venues and Connect apps with one team. Changes to these routes are additive only from here on. - name: Market data description: >- Search and look up symbols, read price history and quotes, check the server clock, and stream live bars. Crypto prices come from each provider’s public feed. Futures prices are licensed to each user and stream only from that trader’s own futures source: a login on their venue’s production Rithmic system, under their own market data subscription. A Rithmic Test login carries no market data. Without a source, a futures request answers 503 `feed_requires_connection` and the symbol search lists no futures. - name: News description: >- Market news and the economic calendar, from licensed and open sources, tagged with futures roots as they arrive. The content is the same for everyone, and these routes admit the same callers as market data: a licensed origin, a session or a Trading API key. Page headlines by publish time, filter them by instrument root, and stream them live over server-sent events. Thumbnails come through the image route. - name: Trading description: >- Place, change and cancel orders, set a position’s exits, and close or flatten positions. Every call that places an order takes a `clientOrderId` as its idempotency key. - name: Account description: >- Read an account a trader can trade: its balance, positions, working orders, fills, profit and loss history, and the live account stream. You don’t create accounts here. A trader connects their own account at a provider, or opens their own Demo on the paper book, in the trdrs app. A venue issues accounts on the paper book with Issue an account into a group, and a venue pre-registers accounts at a provider through Connect with Pre-register a trader’s account. - name: Connect description: >- Connect is the account picker a trader opens: in the trdrs app, where it lists the built-in providers and every listed venue, and in hosted Connect on a Connect app’s website, where it lists the tiles the app chose. The pre-registration routes let a venue fill Connect in the trdrs app ahead of time, for a trader who signs in to trdrs. You tell trdrs that a trader has an account at a built-in provider: their sign-in email, and optionally the account number and login name. When that trader signs in, Connect shows the account ready to link, and they sign in to the provider themselves, once. The trader types their own password, and access starts when their own login succeeds. You can list who you pre-registered and who has linked, and cancel a pre-registration that hasn’t been used. A pre-registration expires after 30 days, and sending it again refreshes it. These routes take the pre-registration key. The whole flow is in the **[Quick Start](/docs/guides/quick-start)**. - name: Connect apps preview description: >- Run a Connect app: your own trading interface, whose traders connect their accounts in hosted Connect on your website and trade them on your screens. The Connect API is what your backend calls with your app’s API key: Create a Connect link, read and close it, and the account, market and trading routes with your trader named in `x-trdrs-trader`. Hosted Connect calls its own routes with the frame session a Connect link opens. The Connect dashboard calls the rest with your Connect sign-in session: your apps, each app’s name and logo, API keys, websites, tiles, white-label paper and Demos, traders and active traders, invoices, conformance runs and its Connect pass. These routes are in preview, served on the sandbox, where they are free. Once production opens to Connect apps, it serves the route that records an app’s Connect pass, which opens the app’s production. - name: Connect accounts description: >- A Connect client's team signs in to the Connect dashboard with a Connect account of its own, never a trader's, and one login reaches both environments. Production answers a short statement for the signed-in account, naming its verified email and the Connect apps it owns, and sandbox exchanges it for a sandbox session and the counterpart app of each: the sandbox app that stands for the production one. The environments share no credential: production signs the statement with its own key, and sandbox checks it with production's public key alone. These routes take the Connect dashboard's own session, from the dashboard's origin; a trader's session and every key are refused, and a Connect account's session reaches no trading, account, market or AI route. - name: Challenges description: >- These routes list evaluation programs and a trader’s own enrollments. **Preview: the one group in this reference outside the additive-only guarantee.** Their shapes will change when challenges are rebuilt; see Stability. **They take a signed-in session, not a key**, and are served only where the engine runs with `CHALLENGES_ENABLED`. Without it, the routes don’t exist and every one answers `404`. The administration half isn’t documented here, because it is trdrs’s own tooling, not part of the API. paths: /api/pre-registration/conformance/runs: post: tags: - Connect summary: Start a sandbox conformance run description: >- Opens a free two-hour conformance run in the sandbox. During the run, trdrs watches the requests you make with your pre-registration and Trading API keys, and injects one rate limit, one risk lock and one dropped account and market stream for your client to handle. You can have one run open at a time. Required key: pre-registration key, in the sandbox. responses: '201': description: The run, with its results so far. content: application/json: schema: $ref: '#/components/schemas/ConformanceResponse' '401': description: >- `pre_registration_key_required`: a valid sandbox pre-registration key is required. '409': description: >- `sandbox_only`: this isn't the sandbox. `run_open`: you already have a run open, and `runId` names it. security: - preRegistrationKey: [] servers: - url: https://sandbox.trdrs.co description: Sandbox only x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://sandbox.trdrs.co/api/pre-registration/conformance/runs', { method: 'POST', headers: { Authorization: `Bearer ${process.env.TRDRS_API_KEY}` }, }) const data = await res.json() - lang: shell label: cURL source: >- curl -X POST 'https://sandbox.trdrs.co/api/pre-registration/conformance/runs' \ -H "Authorization: Bearer $TRDRS_API_KEY" components: schemas: ConformanceResponse: type: object description: A conformance run, with its grade and the rules it checks. required: - run properties: run: $ref: '#/components/schemas/ConformanceRun' grade: $ref: '#/components/schemas/ConformanceGrade' rules: type: array description: The rules the run checks, with how to exercise each. items: type: object properties: id: type: string description: The rule's id. title: type: string description: What the rule checks. kind: type: string description: '`passive` or `injected`.' minObservations: type: integer description: How many times the rule must be seen to pass. howToExercise: type: string description: What your client should do so the rule is exercised. attestation: type: - string - 'null' description: >- What you attest to separately, because the run can't measure it, or null when the run measures every rule. example: run: id: 96507d96-8c4f-4b84-a718-a72dd77ba104 status: open ruleset: partner rulesetVersion: '1.0' openedAt: '2026-09-11T12:00:00.000Z' expiresAt: '2026-09-11T14:00:00.000Z' closedAt: null certificateExpiresAt: null grade: ruleset: partner rulesetVersion: '1.0' passed: false outstanding: - stream_reconnect results: - rule: stream_reconnect title: Streams recover from a reconnect snapshot kind: injected outcome: not_exercised passes: 0 failures: 0 note: Open an account stream and reconnect after the sandbox drops it. ConformanceRun: type: object description: One conformance run in the sandbox. required: - id - status - ruleset - rulesetVersion - openedAt - expiresAt - closedAt - certificateExpiresAt properties: id: type: string format: uuid description: The run's id. ruleset: type: string enum: - partner - connect description: >- The rules the run checks: `partner` for a venue's run with its pre-registration key, `connect` for a Connect app's run with its API key. status: type: string enum: - open - passed - failed - expired description: >- Where the run stands: open, then passed or failed when you finish it, or expired when its two hours run out. rulesetVersion: type: string description: The version of the rules the run checks. openedAt: type: string format: date-time description: When the run opened. expiresAt: type: string format: date-time description: When the run expires. closedAt: type: - string - 'null' format: date-time description: When the run was finished, or null while it is open. certificateExpiresAt: type: - string - 'null' format: date-time description: >- When the certificate a passed run earned expires, twelve months after it passed, or null for a run that didn't pass. ConformanceGrade: type: object description: How the run did against each rule. required: - ruleset - rulesetVersion - passed - outstanding - results properties: ruleset: type: string enum: - partner - connect description: The rules checked. rulesetVersion: type: string description: The version of the rules checked. passed: type: boolean description: True when every rule was exercised and passed. outstanding: type: array items: type: string description: The rules not yet passed. results: type: array description: One result per rule. items: type: object required: - rule - title - kind - outcome - passes - failures - note properties: rule: type: string description: The rule's id. title: type: string description: What the rule checks. kind: type: string enum: - passive - injected description: >- `passive` rules are checked on your ordinary requests. `injected` rules check how your client handles a problem the sandbox causes on purpose. outcome: type: string enum: - pass - fail - not_exercised description: Whether the rule passed, failed, or hasn't been exercised yet. passes: type: integer description: How many times it was seen to pass. failures: type: integer description: How many times it was seen to fail. note: type: - string - 'null' description: More detail, or null. securitySchemes: preRegistrationKey: type: http scheme: bearer description: >- The pre-registration key (`trdrs_sk_…`), issued to a venue for Connect pre-registration and conformance runs in the sandbox. It works only on those routes under `/api/pre-registration/`, outside the venue routes. It looks like a Trading API key but has a different scope: a Trading API key is refused here, and a pre-registration key is refused everywhere else. A venue’s backend calls the venue routes with its Venue key. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.