Usage by token
The same usage figures as /accounts/usage/, split by API token instead of totalled for the account.
This is for platforms that hand each of their own customers a separate Generect token. You get, per token: how many requests it made, which endpoints it called, and how many of those succeeded or failed — enough to attribute cost to the customer who caused it, or to spot the one client whose integration is retrying in a loop.
You only ever see your own tokens, never another account’s. If you do not pass dates, the report covers the last 30 days.
Use Case:
If you resell Generect inside your own product, you probably issue one token per customer. This endpoint tells you what each of those tokens actually did, so you can bill the right customer, see who is close to their limit, and catch a broken integration before it shows up on your invoice. Ask for a single client withclient_id, or leave it off to get every token at once. Tokens with no traffic in the period are still listed, at zero — useful for spotting a customer who has stopped using you.Authorizations
Use the required Token prefix. Example: Authorization: Token xxxxxxxxx
Query Parameters
Restrict the report to the token carrying this client identifier — the value set when the token was created.
Restrict the report to one exact token value.
Start of the reporting window. Accepts YYYY-MM-DD or a full ISO timestamp. Defaults to 30 days ago.
End of the reporting window, inclusive. Defaults to now. A date with no time means midnight, so end_date=2026-05-31 stops at the very start of the 31st and that day's traffic is not counted — pass 2026-05-31T23:59:59 (or the 1st of the next month) to include it.
IANA timezone used to render the period bounds in the response. It does not change which requests are counted: the default window is anchored to the same instant whichever zone you name. An unrecognised name is rejected with 400.
Response
Per-token usage analytics