> ## 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. # Read the venue instrument reference catalog > 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:read. Returns the same static futures contract facts used by the Trading API, so a venue can build instrument candidates without obtaining a personal Trading API key. This is reference data only: it does not activate an instrument, grant market-data entitlement or say an account may trade it. ## OpenAPI ````yaml /partner-platform/openapi.json get /api/operator/venues/{venueId}/reference/instruments 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}/reference/instruments: get: tags: - Venue platform preview summary: Read the venue instrument reference catalog 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:read. Returns the same static futures contract facts used by the Trading API, so a venue can build instrument candidates without obtaining a personal Trading API key. This is reference data only: it does not activate an instrument, grant market-data entitlement or say an account may trade it. parameters: - name: venueId in: path required: true schema: type: string format: uuid responses: '200': description: 'Scoped result. Cache-Control: no-store.' content: application/json: schema: $ref: '#/components/schemas/VenueInstrumentReferenceResponse' '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}/reference/instruments', { credentials: 'include', }) const data = await res.json() - lang: shell label: cURL source: >- curl 'https://app.trdrs.co/api/operator/venues/{venueId}/reference/instruments' \ -b "session=$TRDRS_SESSION" components: schemas: VenueInstrumentReferenceResponse: type: object additionalProperties: false properties: instruments: type: array items: $ref: '#/components/schemas/ContractSpec' required: - instruments example: instruments: - root: ES name: E-mini S&P 500 exchange: CME tickSize: 0.25 tickValue: 12.5 multiplier: 50 cycle: quarterly ErrorResponse: type: object properties: error: type: string required: - error example: error: invalid_instrument ContractSpec: type: object description: >- ContractSpec. One futures product: its listing exchange, tick size and tick value, the dollar multiplier, its roll cycle, and the calendar months it lists when the roll is not modelled. Static reference data — the facts an order ticket sizes and snaps against. properties: root: type: string description: Product root, e.g. `ES`. name: type: string exchange: type: string description: Listing exchange in canonical form, e.g. `CME`. tickSize: type: number tickValue: type: number description: Dollar value of one tick for one contract. multiplier: type: number description: >- Dollar value of a 1.0 price move for one contract (tickValue / tickSize). cycle: type: - string - 'null' enum: - quarterly - null description: >- `quarterly` = the front month resolves automatically (Mar/Jun/Sep/Dec). `null` = a product-specific roll the engine does not approximate, so an order must name its contract month. months: type: array items: type: integer minimum: 1 maximum: 12 description: >- The calendar months (1-12) a `cycle: null` product lists contracts in. Absent on quarterly products. fractionalPrice: type: boolean description: >- True when the exchange quotes the product as counted thirty-seconds of a point rather than in decimals (the CBOT Treasury convention). It is a quotation fact independent of tickSize, and drives the fractional price format on /api/market/symbol-info. Absent means decimal. priceFraction: $ref: '#/components/schemas/PriceFraction' description: >- The executable counted-fraction facts of a root the exchange quotes in thirty-seconds, present exactly where fractionalPrice and tickSize together name one of the three writings. Absent means the product is priced in decimals, so size and snap against tickSize. Read it rather than deriving a denominator from the tick. nominalInitialMargin: type: number description: >- Nominal per-contract initial margin in dollars — a maintained estimate for backtests, never a live money figure. nominalDayMargin: type: number description: >- Nominal per-contract day-trading margin in dollars — the same estimate posture. required: - root - name - exchange - tickSize - tickValue - multiplier - cycle PriceFraction: type: object description: >- PriceFraction. The counted-fraction facts of a product the exchange quotes in thirty-seconds, in executable form: denominator is the number of parts one point divides into, and subFraction says into how many parts one of those divides again where the writing divides it. A 1/32 tick states { denominator: 32 }, a 1/64 tick { denominator: 64, subFraction: 2 }, a 1/128 tick { denominator: 128, subFraction: 4 }. These are the only three writings; a product quoted in decimals carries no PriceFraction at all. properties: denominator: type: integer enum: - 32 - 64 - 128 description: Parts one point divides into subFraction: type: integer enum: - 2 - 4 description: >- Parts one of those divides again: 2 is halves of a thirty-second, 4 is quarters. Absent for a whole thirty-second. required: - denominator 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. ````