> ## 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. # List billed accounts > Returns each account that counted toward `activeAccounts` in the month, with the real fills that made it count and when the first and last of them happened — the reconciliation companion to `/api/partner/usage`. The list is computed from the same query as the count, so it always sums to the billed number — when your records disagree with an invoice, this is the level where the difference shows up. Accounts are named by their venue account number — the identifier your firm issued when it created them. No trader identity fields appear on this surface. Scope, month semantics, and refusals are exactly those of `/api/partner/usage`: your own firm only, resolved from the key; `month` is `YYYY-MM` UTC defaulting to the previous complete month; a malformed month is a 400; and a deployment without metering answers 404 rather than an empty list that would read as "no accounts billed". ## OpenAPI ````yaml /partner-platform/openapi.json get /api/partner/usage/accounts 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: >- Disabled private-preview venue configuration APIs. VENUE_CONFIGURATION_ENABLED and a vault are required. Every route documented here under /api/partner/ is also served under /api/operator/ to a verified owner session, by the same router with a different credential: a browser must never hold a venue key, so an operator console reaches the identical checks that way rather than through a second copy of this surface. Not part of the stable public contract until qualification and release; existing partner APIs 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 venue’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 firm 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 surface: 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 broker account (or creates a free demo account) in the app, and firms create evaluation accounts through the Partner API (Firm accounts → Create evaluation accounts) or register venue accounts through Connect (Create an account registration). 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 partner’s site: the brokers we run, plus every listed venue. These three routes are how a firm PRE-FILLS it. You tell us a trader has an account at a broker we support (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 type only their own password. 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 API key today and are Connect’s own; they are not part of the legacy firm-operations surface. The end-to-end flow is **[Quick Start](/docs/guides/quick-start)**. - name: Firm accounts (legacy) description: >- Legacy. 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 doors. Evaluation accounts your firm issues on the trdrs venue, through your partner key — the other half of account setup. Connect registrations hand off accounts that exist on your venue; these routes create and manage accounts on ours: 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, 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 API key. - name: Webhooks description: >- Being replaced by the venue API: venue-scoped events are not built yet, so this is the one job a venue-only backend still needs a Partner key for; 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 brokers and prop firms alike: the account-registration (`registration.*`) events fire wherever Connect does, and the account events fire where the prop engine runs. - name: Challenges description: >- Being replaced by the venue API: stage rules on the venue carry the firm’s half of this; the trader’s enroll flow has not moved yet. The prop evaluation surface: 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 firm-console/admin half of this surface is deliberately not documented here. It is back office, not licensed surface. paths: /api/partner/usage/accounts: get: tags: - Billing summary: List billed accounts description: >- Returns each account that counted toward `activeAccounts` in the month, with the real fills that made it count and when the first and last of them happened — the reconciliation companion to `/api/partner/usage`. The list is computed from the same query as the count, so it always sums to the billed number — when your records disagree with an invoice, this is the level where the difference shows up. Accounts are named by their venue account number — the identifier your firm issued when it created them. No trader identity fields appear on this surface. Scope, month semantics, and refusals are exactly those of `/api/partner/usage`: your own firm only, resolved from the key; `month` is `YYYY-MM` UTC defaulting to the previous complete month; a malformed month is a 400; and a deployment without metering answers 404 rather than an empty list that would read as "no accounts billed". parameters: - name: month in: query schema: type: string pattern: ^\d{4}-\d{2}$ description: >- The month to report, `YYYY-MM`. Defaults to the previous complete month. responses: '200': description: >- The accounts that counted in the month (PartnerUsageAccountsResponse) content: application/json: schema: $ref: '#/components/schemas/PartnerUsageAccountsResponse' '400': description: >- `month` is not `YYYY-MM`. Rejected rather than silently reset to a default month. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: The bearer is not a partner-scoped key for an active partner firm content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: >- Metering is not enabled on this deployment, or no usage record exists for the firm. Never answered as an empty list. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - partnerKey: [] x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://app.trdrs.co/api/partner/usage/accounts?month=2026-07', { headers: { Authorization: `Bearer ${process.env.TRDRS_API_KEY}` }, }) const data = await res.json() - lang: shell label: cURL source: >- curl 'https://app.trdrs.co/api/partner/usage/accounts?month=2026-07' \ -H "Authorization: Bearer $TRDRS_API_KEY" components: schemas: PartnerUsageAccountsResponse: type: object description: >- PartnerUsageAccountsResponse. The accounts behind the usage number — always sums to `activeAccounts` for the same month. properties: firm: type: string description: Your firm’s name, as trdrs holds it. month: type: string description: The month reported, `YYYY-MM` (UTC). basis: type: string enum: - rithmic-system - unattributable description: >- How accounts were attributed — same meaning as on `/api/partner/usage`. `unattributable` comes with an empty list. accounts: type: array description: One entry per account that counted, ordered by account number. items: type: object properties: accountNumber: type: string description: The venue account number — the identifier your firm issued. fills: type: integer description: Real fills inside the month. Simulated fills never count. firstFillAt: type: string format: date-time description: The first real fill in the month (UTC). lastFillAt: type: string format: date-time description: The last real fill in the month (UTC). required: - accountNumber - fills - firstFillAt - lastFillAt required: - firm - month - basis - accounts example: firm: yourfirm month: 2026-07 basis: rithmic-system accounts: - accountNumber: YF-EVAL-10021 fills: 44 firstFillAt: '2026-07-01T13:31:02Z' lastFillAt: '2026-07-30T19:58:41Z' - accountNumber: YF-EVAL-10044 fills: 3 firstFillAt: '2026-07-14T15:02:10Z' lastFillAt: '2026-07-14T15:40:55Z' - accountNumber: YF-FUNDED-2007 fills: 129 firstFillAt: '2026-07-01T13:30:00Z' lastFillAt: '2026-07-31T20:14:09Z' ErrorResponse: type: object properties: error: type: string required: - error example: error: invalid_instrument securitySchemes: partnerKey: type: http scheme: bearer description: >- A partner-scoped API key (`trdrs_sk_…`), issued to a trdrs Connect partner firm and accepted only under `/api/partner/`. Same format as the firm (`tenant`) key, different scope: a firm API key is refused here, and this key is refused everywhere else. ````