> ## 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. # Get monthly usage > Returns what your firm is billed for in one month, computed from the execution ledger: `activeAccounts` is the number of distinct accounts that took at least one real fill inside the month. An account that connected but never traded does not count, and simulated fills never count. These are the same numbers the trdrs invoice is computed from, from the same query, so you can reconcile a bill without asking us for a breakdown. Scope is your own firm and nothing else. The firm is resolved from your key, not from a parameter, so there is no argument that reaches another firm’s accounts. `month` is `YYYY-MM` and defaults to the previous complete month, the one being invoiced. Naming the current month is allowed and answers month-to-date, which keeps moving until the month closes. Months are UTC. `basis` says how the count was attributed. `rithmic-system` means accounts were matched to your system, the normal case. `unattributable` means this deployment cannot attribute accounts to your firm on your connector, so the count is `0` and `amountCents` is null rather than a figure that looks like a real zero bill. ## OpenAPI ````yaml /partner-platform/openapi.json get /api/partner/usage 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: get: tags: - Billing summary: Get monthly usage description: >- Returns what your firm is billed for in one month, computed from the execution ledger: `activeAccounts` is the number of distinct accounts that took at least one real fill inside the month. An account that connected but never traded does not count, and simulated fills never count. These are the same numbers the trdrs invoice is computed from, from the same query, so you can reconcile a bill without asking us for a breakdown. Scope is your own firm and nothing else. The firm is resolved from your key, not from a parameter, so there is no argument that reaches another firm’s accounts. `month` is `YYYY-MM` and defaults to the previous complete month, the one being invoiced. Naming the current month is allowed and answers month-to-date, which keeps moving until the month closes. Months are UTC. `basis` says how the count was attributed. `rithmic-system` means accounts were matched to your system, the normal case. `unattributable` means this deployment cannot attribute accounts to your firm on your connector, so the count is `0` and `amountCents` is null rather than a figure that looks like a real zero bill. 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 firm’s usage for the month (PartnerUsageResponse) content: application/json: schema: $ref: '#/components/schemas/PartnerUsageResponse' '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 a zero. 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?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?month=2026-07' \ -H "Authorization: Bearer $TRDRS_API_KEY" components: schemas: PartnerUsageResponse: type: object description: >- PartnerUsageResponse. Money is in cents and integral; a null price or amount means unpriced, never a zero bill. 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. `unattributable` means this connector cannot attribute per firm here, so the count is 0 by construction. activeAccounts: type: integer description: >- Distinct accounts with at least one real fill in the month. Connected-but-idle does not count; simulated fills never count. priceCentsPerActiveAccount: type: - integer - 'null' description: >- Your agreed per-active-account price in cents. Null when no price is set. amountCents: type: - integer - 'null' description: >- `activeAccounts` × price, in cents. Null when unpriced or unattributable, never coerced to 0. required: - firm - month - basis - activeAccounts - priceCentsPerActiveAccount - amountCents example: firm: yourfirm month: 2026-07 basis: rithmic-system activeAccounts: 128 priceCentsPerActiveAccount: 200 amountCents: 25600 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. ````