Read your usage

Read the number your venue is billed on, and the accounts behind it, from two venue routes. Both are computed from the same query as the trdrs invoice, so the account list always sums to the billed number, and you can check an invoice account by account without asking anyone. Use this page when your finance team reconciles a trdrs invoice, or when you want to watch a month as it runs. Both routes take a Venue key or the back office’s signed-in session. Required scope: venue:read.

Read the month's number

GET /api/venues/{venueId}/usage answers with the count, the price and the total.

curl "$TRDRS_API_BASE_URL/api/venues/$VENUE/usage?month=2026-07" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY"

{
  "venue": "Your Venue",
  "month": "2026-07",
  "basis": "rithmic-system",
  "activeAccounts": 128,
  "priceCentsPerActiveAccount": 200,
  "amountCents": 25600,
  "currency": "USD"
}

Money is in whole US cents. A null price or amount means the month isn’t priced, never a zero bill. currency is always USD, the currency trdrs bills in, whatever the currency of your paper accounts.

Pull the accounts behind it

GET /api/venues/{venueId}/usage/accounts expands the same query into one row per account that counted, ordered by account number.

curl "$TRDRS_API_BASE_URL/api/venues/$VENUE/usage/accounts?month=2026-07" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY"

Each row carries the accountNumber, the count of real fills inside the month, and firstFillAt and lastFillAt in UTC. Each account is named by its account number, and the rows carry no trader’s identity.

Watch the month as it runs

Both routes read the previous complete month, the one being invoiced, when you leave month out. Name the current month to read month-to-date, which keeps moving until the month closes.month is YYYY-MM, and months are UTC. A malformed month is refused with 400 invalid_month rather than read as the default, so a typo in a reporting job fails loudly instead of reporting a different month.

Know what the meter counts

activeAccounts is the number of distinct accounts that took at least one real fill inside the month. Three consequences follow from that.

Account	Counts
An account that traded once in the month	Yes, once, however many fills it took
An account that connected but never traded	No
An account whose only fills were simulated	No
An account on the paper book, or at any provider other than Rithmic	No
The same account trading in two different months	Once in each month

Nothing is prorated and no account counts in part: an account either took a real fill inside the UTC month or it didn’t.

Read `basis` before the number

basis says how the accounts were attributed to your venue, and it changes what the number means.

`basis`	What it means	What you get
`rithmic-system`	The accounts were matched to your Rithmic system.	A real count, and a real `amountCents` when a price is set.
`unattributable`	This deployment can’t attribute accounts to your venue on its provider.	`activeAccounts` is `0` and `amountCents` is `null`, so it can’t be mistaken for a real zero bill. The account list is empty for the same reason.

The meter counts real fills at Rithmic on accounts whose login is your Rithmic system, and nothing else. A venue whose accounts are issued on the paper book takes no such fills, so it reads basis: "unattributable", activeAccounts: 0 and amountCents: null, with an empty account list. That’s the meter stating that it measures Rithmic fills alone, and it isn’t a bill of zero.

Reconcile an invoice

Read the month’s number with basis and activeAccounts. If basis is unattributable, stop: the count is a fixed zero, not a measurement, and the invoice question is a commercial one.
Pull the account list for the same month. It always sums to activeAccounts, because it’s the same query expanded, so a difference from your expectation becomes account by account rather than one disputed total.
Compare it with your own records. An account on our list and not on yours traded when you thought it was dormant. An account on yours and not ours took no real fill that month: it was connected but idle, or traded simulated fills only.
Check the arithmetic. amountCents is activeAccounts times priceCentsPerActiveAccount, in cents. A null price means no price is set on your venue, which is a contract question, not a data one.

Both routes cover your venue’s own accounts and nothing else. The venue is the one in the path that your key or session acts for, so no argument reaches another venue’s accounts.

Handle errors

Status	When
`400 invalid_month`	`month` isn’t `YYYY-MM`.
`401 venue_key_required`	The Venue key is missing, malformed, revoked or expired.
`403 permission_denied`	The key is valid but lacks the `venue:read` scope.
`404 not_found`	The venue has no company to read usage for. It’s never answered as a zero or an empty list.

Next steps

Venue accounts

See the accounts that can become billable, and the balance operations your finance team reads.

Register an account

Pre-register an account, the other way an account arrives.

Active traders

See how a Connect app is billed for its active traders.

Start here

Set up your venue

Run accounts

Connect pre-registration

Check your integration

Know what the meter counts

Read `basis` before the number

Reconcile an invoice

Handle errors

Next steps

Venue accounts

Register an account

Active traders

​Know what the meter counts

​Read basis before the number

​Reconcile an invoice

​Handle errors

​Next steps

Venue accounts

Register an account

Active traders

Know what the meter counts

Read `basis` before the number

Reconcile an invoice

Handle errors

Next steps