> ## 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. # Turn level 2 on or off > Preview: served on the sandbox to every venue; production availability is arranged when a venue qualifies. Trading API keys and Partner keys do not authorize these routes. Requires a verified authorized operator session; writes require a trusted origin. venue:configure. Level 2 is the venue running rules, stages and analytics on the accounts it issues. Creating the first group turns it on; this turns it off again, or on by hand. With it off, an issued account trades under the Demo rules and every level 2 tab says its settings are saved and not yet applied. Asking for the state that exists returns the venue unchanged. ## OpenAPI ````yaml /partner-platform/openapi.json post /api/operator/venues/{venueId}/level2 openapi: 3.1.0 info: title: trdrs Engine API version: 1.1.0 description: >- ## API Reference This is the served OpenAPI contract for the trdrs engine: market data, trading and account routes for your firm's traders, trdrs Connect account-registration handoff, and preview challenge routes. See Quick Start for the first integration path: key setup, market config, chart data, Connect account registrations, idempotency, stream reconnects, and conformance. See Overview and API Standards for the cross-cutting contract rules. servers: - url: https://app.trdrs.co description: Production - url: / description: This engine security: [] tags: - name: Venue platform preview description: >- The venue routes, in preview: a venue’s providers, instruments, conditions, groups, routes, stages, level 2, keys, accounts, usage, balance receipts and webhooks. Served on the sandbox to every venue; production availability is arranged when a venue qualifies. Every route documented here under /api/partner/ takes a Venue key and is also served under /api/operator/ to a verified owner session, by the same router with a different credential: a browser never holds a Venue key, so the back office reaches the identical checks that way. Additive-only from here; the Legacy Partner API routes remain unchanged. - name: Market data description: >- Symbol search and resolution, OHLCV history, quote snapshots, the server clock, and the live bar stream. Crypto rides each provider’s public feed; futures stream from the caller’s own connected Rithmic account. With none connected, futures requests answer 503 `feed_requires_connection`. - name: News description: >- Aggregated market news and the economic calendar, from licensed/open sources, keyword-tagged with futures roots at ingest. Platform-wide content (nothing per-user), admitted exactly like Market data: a licensed origin, a session, or a Trading API key. Headlines page by published time, scope by instrument root, and stream live over SSE; thumbnails serve through the image proxy. - name: Trading description: >- The money routes: entries, exits, replaces, cancels, and position/account flattening. Every order-placing call uses `clientOrderId` as its idempotency key. - name: Account description: >- Reading a connected account. You do not create trading accounts here: a trader connects their own account at a provider (or opens their own Demo on the paper book) in the app, and a venue issues accounts on the paper book (Venue platform → Issue an account into a group; the Legacy Partner API’s Create evaluation accounts does the same) or pre-registers accounts at a provider through Connect (Pre-register a trader’s account). Account state and the durable ledgers: balances, positions, working orders, fills, P&L history, and the live account stream. - name: Connect description: >- Connect is the account picker a trader opens, in our app or embedded on a firm’s site: the built-in providers, plus every listed venue. These three routes are how a firm PRE-FILLS it. You tell us 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. Nothing here sends a password or grants access before the trader’s own login succeeds. You can list who you pre-registered and who has linked, and cancel a pre-registration that has not been used. Pre-registrations expire after 30 days; repeating one refreshes it. These routes take the Partner key and are Connect’s own; they are not part of the Legacy Partner API. The end-to-end flow is **[Quick Start](/docs/guides/quick-start)**. - name: Firm accounts (legacy) description: >- Legacy Partner API. Every route in this group has a venue twin under `/api/partner/venues/{venueId}/accounts…`, reached with a Venue key and a named scope, and new integrations use those; this group stays for firms that predate venues, and the same operation runs behind both. Evaluation accounts your firm issues on the paper book, through your Partner key. Connect pre-registers accounts that exist at a provider; these routes create and manage accounts on the paper book: the trader trades them on trdrs, and your firm owns the lifecycle. Every route is scoped to accounts your firm created through this API — an account the same trader opened themselves is invisible and untouchable here, by construction. Creation is batched with per-item results, and every write carries your own `referenceId`, so a crashed pipeline retries safely. Served when the deployment runs the prop engine; without it, every route in this group answers `404`. - name: Billing description: >- Legacy Partner API, per firm. What your firm is billed for in a month, computed from the execution ledger, and the accounts behind the number. The venue platform will carry per-venue usage; until it does these two routes answer the Partner key. - name: Webhooks description: >- Legacy Partner API, being replaced by venue-scoped events, which are not built yet; this is the one job a venue-only backend still needs a Partner key for, and nothing here is removed until they are. The outbound event bus: register an https endpoint and the platform pushes events to it instead of your back office polling us. Every delivery is signed (`trdrs-signature: t=,v1=` over `${t}.${rawBody}`) so you can prove it came from us and is fresh, and every delivery is durable — a failed attempt is retried with backoff for about nine hours and the whole log is readable, so an endpoint that was down is a delay rather than a lost event. Serves every venue alike: the account-registration (`registration.*`) events fire wherever Connect does, and the account events fire where the prop engine runs. - name: Challenges description: >- Legacy Partner API, being replaced by stage rules on the venue, which carry the firm’s half of this; the trader’s enroll flow has not moved yet. The prop evaluation routes: challenge programs and a trader’s own enrollments. **Preview: the one group on this page outside the additive-only guarantee** (the pre-contract v1 scaffold; the Phase-1 rebuild will change these shapes; see Stability). **Cookie-authenticated, not key-authenticated**, and served only when the engine runs with `CHALLENGES_ENABLED`; without that flag the bundle is absent and every route below returns `404`. The admin half of this is deliberately not documented here. It is platform administration, not licensed API. paths: /api/operator/venues/{venueId}/level2: post: tags: - Venue platform preview summary: Turn level 2 on or off description: >- Preview: served on the sandbox to every venue; production availability is arranged when a venue qualifies. Trading API keys and Partner keys do not authorize these routes. Requires a verified authorized operator session; writes require a trusted origin. venue:configure. Level 2 is the venue running rules, stages and analytics on the accounts it issues. Creating the first group turns it on; this turns it off again, or on by hand. With it off, an issued account trades under the Demo rules and every level 2 tab says its settings are saved and not yet applied. Asking for the state that exists returns the venue unchanged. parameters: - name: venueId in: path required: true schema: type: string format: uuid - name: Idempotency-Key in: header required: true schema: type: string minLength: 1 maxLength: 128 requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/VenueLevel2Request' responses: '200': description: 'Scoped result. Cache-Control: no-store.' content: application/json: schema: $ref: '#/components/schemas/VenueLevel2Response' '400': description: Invalid input, cursor or required request/version header. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: Required credential missing or invalid. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: >- Verified identity, current owner membership or required scope missing. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: Disabled feature, unavailable resource or wrong venue/environment. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '409': description: Changed idempotent request or stale version. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '413': description: Request exceeds the bounded body size. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '415': description: JSON body required. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '503': description: Service or credential vault unavailable; no success is implied. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - sessionCookie: [] x-codeSamples: - lang: javascript label: TypeScript source: >- // First-party cookie auth: this runs in a signed-in trdrs session, not under an API key. const res = await fetch('https://app.trdrs.co/api/operator/venues/{venueId}/level2', { method: 'POST', headers: { 'content-type': 'application/json', "Idempotency-Key": "example-request-1", }, credentials: 'include', body: JSON.stringify({ "enabled": false }), }) const data = await res.json() - lang: shell label: cURL source: >- curl -X POST 'https://app.trdrs.co/api/operator/venues/{venueId}/level2' \ -b "session=$TRDRS_SESSION" \ -H 'Idempotency-Key: example-request-1' \ -H 'content-type: application/json' \ -d '{"enabled":false}' components: schemas: VenueLevel2Request: type: object additionalProperties: false properties: enabled: type: boolean required: - enabled example: enabled: false VenueLevel2Response: type: object additionalProperties: false properties: venue: $ref: '#/components/schemas/VenueRecord' required: - venue example: venue: id: 00000000-0000-0000-0000-000000000001 organizationId: 00000000-0000-0000-0000-000000000001 legacyFirmId: null name: Example venue description: null environment: sandbox state: draft version: 2 createdAt: '2026-09-14T12:00:00.000Z' level2: enabled: false applies: orders: true fills: true stages: true appliesAtProvider: orders: false fills: false stages: true company: null ErrorResponse: type: object properties: error: type: string required: - error example: error: invalid_instrument VenueRecord: type: object additionalProperties: false properties: id: type: string format: uuid organizationId: type: string format: uuid legacyFirmId: type: - string - 'null' format: uuid name: type: string description: type: - string - 'null' environment: type: string enum: - sandbox - production state: type: string enum: - draft - active - halted version: type: integer createdAt: type: string format: date-time level2: type: object additionalProperties: false properties: enabled: type: boolean applies: type: object additionalProperties: false properties: orders: type: boolean fills: type: boolean stages: type: boolean required: - orders - fills - stages appliesAtProvider: type: object additionalProperties: false properties: orders: type: boolean fills: type: boolean stages: type: boolean required: - orders - fills - stages required: - enabled - applies - appliesAtProvider description: >- Level 2 is the venue running rules, stages and analytics on the accounts it holds. enabled is the venue's own switch, turned on when the firm creates its first group. applies is what this engine build actually applies from the venue's settings to an account issued on the paper book: orders (halt, instrument list, size and notional limits before the claim), fills (markup, collar and commission at the fill) and stages (eligibility read from the account's own fills). appliesAtProvider is the same three for an account held at a provider: its orders and fills are the provider's own, so only stages, read from the provider's records of its fills, is applied. A false entry means the setting is saved and not yet applied to trading, and the back office says so from this field rather than deciding for itself. company: oneOf: - $ref: '#/components/schemas/CompanyRecord' - type: 'null' description: >- The company this venue is the operational half of: its brand, its roles and its listing state live there. Null only on a venue older than the company table that the backfill could not name. required: - id - organizationId - legacyFirmId - name - description - environment - state - version - createdAt - level2 - company CompanyRecord: type: object additionalProperties: false properties: id: type: string format: uuid name: type: string blurb: type: - string - 'null' logoUrl: type: - string - 'null' logoBleed: type: boolean referralUrl: type: - string - 'null' sortOrder: type: integer kind: type: string enum: - prop - broker - crypto - market builtInProvider: type: - string - 'null' enum: - rithmic - tastytrade - hyperliquid - binance - bybit - paper - null connectsTraders: type: boolean pluggable: type: boolean runsVenue: type: boolean listingState: type: string enum: - draft - conformance_passed - submitted - in_review - changes_requested - approved - listed - suspended enabled: type: boolean createdAt: type: string format: date-time required: - id - name - blurb - logoUrl - logoBleed - referralUrl - sortOrder - kind - builtInProvider - connectsTraders - pluggable - runsVenue - listingState - enabled - createdAt description: >- One record per company, with the roles it plays ticked: traders connect their own account through it (connectsTraders), a venue may plug it in (pluggable), it runs a venue (runsVenue). Where a company shows up follows from the roles. The six built-in providers are rows (builtInProvider set). The brand and the listing state live here. securitySchemes: sessionCookie: type: apiKey in: cookie name: session description: >- The signed session cookie of a logged-in trdrs user. First-party/browser only; an API key cannot reach a route secured this way. ````