> ## 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: 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: >-
      trdrs Connect account registration, for partner firms. Register an account
      you issued on your own venue — a pending account registration — with the
      trader’s sign-in email, optionally the venue account id and the login name
      your venue issued. The trader finds it waiting in the connect flow the
      moment they sign in with that email: the connect step is pre-filled with
      everything except the credential, which the trader always enters
      themselves. A registration never transmits a password and never grants
      access to anything before the trader’s own login succeeds. These routes
      answer a partner-scoped key only; a firm API key or a user session gets
      401. Registrations expire after 30 days; re-registering the same email +
      account refreshes the expiry instead of duplicating. The end-to-end flow
      guide is **[Quick Start](/docs/guides/quick-start)**.
  - name: Firm accounts
    description: >-
      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: Webhooks
    description: >-
      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=<unix>,v1=<hmac-sha256>` 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: >-
      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:
        - Connect
      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.

````