> ## 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 traders your Connect made active > Lists the traders who filled an order through your Connect in one month, each once, by your own id for them, with every account behind them: their Paper account and each account they connected. A Connect client is billed per active trader, however many accounts each one trades, under signed terms from the month they start. Where the month is invoiced with them, `frozen` is true and the list is the invoice's own; otherwise it is counted now. Money is in US cents. A null price or amount means no signed terms price the month, never a zero bill, and an `exempt` or `unattributable` month carries no count at all. Required scope: `trader:read`. Preview: served on the sandbox to every venue, and production availability is arranged when a venue qualifies. Trading API keys and Partner keys do not authorize these routes. ## OpenAPI ````yaml /api/openapi.json get /api/partner/venues/{venueId}/usage/traders 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, Connect pre-registration, 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/partner/` takes a Venue key. The back office reaches the same routes under `/api/operator/` with a verified owner’s session, because a browser never holds a Venue key, and both run the same checks. 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 firm’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 firm 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 or embedded on a firm’s site. It lists the built-in providers and every listed venue. The pre-registration routes let a firm fill it in ahead of time. 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. 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 hasn’t been used. A pre-registration expires after 30 days, and sending it again refreshes it. These routes take the Partner key. The whole flow is in the **[Quick Start](/docs/guides/quick-start)**. - 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/partner/venues/{venueId}/usage/traders: get: tags: - Venue platform preview summary: Read the traders your Connect made active description: >- Lists the traders who filled an order through your Connect in one month, each once, by your own id for them, with every account behind them: their Paper account and each account they connected. A Connect client is billed per active trader, however many accounts each one trades, under signed terms from the month they start. Where the month is invoiced with them, `frozen` is true and the list is the invoice's own; otherwise it is counted now. Money is in US cents. A null price or amount means no signed terms price the month, never a zero bill, and an `exempt` or `unattributable` month carries no count at all. Required scope: `trader:read`. Preview: served on the sandbox to every venue, and production availability is arranged when a venue qualifies. Trading API keys and Partner keys do not authorize these routes. parameters: - name: venueId in: path required: true schema: type: string format: uuid - name: month in: query required: false schema: type: string pattern: ^\d{4}-\d{2}$ description: >- The month, as `YYYY-MM` in UTC. Leave it out for the previous complete calendar month, the one being invoiced. The current month counts what has filled so far. responses: '200': description: >- Success. The response is sent with `Cache-Control: no-store`, so don't cache it. content: application/json: schema: $ref: '#/components/schemas/VenueUsageTradersResponse' '400': description: '`invalid_month`: `month` isn''t a valid `YYYY-MM`.' content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: >- The Venue key or the session is missing, malformed, revoked or expired. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: >- The credential is valid but can't do this: the key lacks the scope or its creator is no longer an owner, the email isn't verified, a reader tried to write, or the request came from an origin that isn't trusted. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: >- The venue, account or resource doesn't exist in this environment, or isn't yours to see. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '409': description: >- The request conflicts with what is stored: the `Idempotency-Key` was used with a different body, or the version you sent is stale. The `error` code names the conflict. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '413': description: The body is larger than this route accepts. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '415': description: 'Send the body as JSON, with `Content-Type: application/json`.' content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '503': description: >- trdrs can't complete the request right now, because a part of the venue platform or its credential store is unavailable. Don't assume a write happened: retry it with the same `Idempotency-Key`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - venueOperatorKey: [] x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://app.trdrs.co/api/partner/venues/{venueId}/usage/traders', { headers: { Authorization: `Bearer ${process.env.TRDRS_VENUE_KEY}` }, }) const data = await res.json() - lang: shell label: cURL source: >- curl 'https://app.trdrs.co/api/partner/venues/{venueId}/usage/traders' \ -H "Authorization: Bearer $TRDRS_VENUE_KEY" components: schemas: VenueUsageTradersResponse: type: object additionalProperties: false properties: month: type: string frozen: type: boolean invoiceState: type: - string - 'null' currency: const: USD basis: type: string enum: - connect-traders - exempt - unattributable reason: type: string description: >- Why the month carries no count: `internal_venue` or `missing_trade_dates`. Only on an `exempt` or `unattributable` month. activeTraders: type: - integer - 'null' priceCentsPerActiveTrader: type: - integer - 'null' amountCents: type: - integer - 'null' traders: type: array items: type: object additionalProperties: false properties: trader: type: string fills: type: integer accounts: type: array items: type: object additionalProperties: false properties: accountId: type: string kind: type: string enum: - paper - connected description: >- `paper`: the trader's Paper account in your Connect. `connected`: an account they connected through your Connect. provider: type: string accountNumber: type: string environment: type: - string - 'null' fills: type: integer firstFillAt: type: string format: date-time lastFillAt: type: string format: date-time required: - accountId - kind - provider - accountNumber - environment - fills - firstFillAt - lastFillAt required: - trader - fills - accounts required: - month - frozen - invoiceState - currency - basis - reason - activeTraders - priceCentsPerActiveTrader - amountCents - traders example: month: 2026-11 frozen: true invoiceState: draft currency: USD basis: connect-traders activeTraders: 1 priceCentsPerActiveTrader: 200 amountCents: 200 traders: - trader: trader-8841 fills: 61 accounts: - accountId: 3f9c2a9b8e7d6c5b4a39281706f5e4d3 kind: paper provider: paper accountNumber: DEMO-7C21A9 environment: null fills: 40 firstFillAt: '2026-11-03T14:31:07.000Z' lastFillAt: '2026-11-27T19:58:40.000Z' - accountId: a1b2c3d4e5f60718293a4b5c6d7e8f90 kind: connected provider: rithmic accountNumber: APEX-123456 environment: prod fills: 21 firstFillAt: '2026-11-05T15:02:11.000Z' lastFillAt: '2026-11-20T18:44:09.000Z' ErrorResponse: type: object description: >- The body of every error response. It always carries `error`, an English sentence you can show. A refused trading request also carries `code`, one of the refusal codes, and `params`, the details of that refusal. Translate by `code` and `params`, and show a generic message for a code you don't recognize. Other errors may carry a `code` of their own. properties: error: type: string description: What went wrong, as an English sentence. code: type: string description: >- A stable machine code. On a refused trading request, it is one of the refusal codes. params: type: object description: >- The details of the refusal named by `code`, on a refused trading request. required: - error example: error: invalid_instrument securitySchemes: venueOperatorKey: type: http scheme: bearer description: >- The Venue key (`trdrs_vk_sandbox_…` or `trdrs_vk_production_…`), in preview. It belongs to one venue in one environment and carries the scopes it was created with. The venue's verified owner creates it while signed in. It works on the `/api/partner/venues/{venueId}` routes and, with `trader:read` or `trader:trade`, on the account, market and trading routes for the venue's own traders, each request naming its trader in `x-trdrs-trader`. A `trdrs_sk_…` key can't be used in its place. It never signs in, manages keys or reaches a trdrs user's accounts. Keep it on your server. ````