Usage statistics
GET /api/v1/console/stats returns call counts and latency metrics grouped by a time period you choose. Use this to spot trends — a sudden spike in error calls, a latency regression, or unusual traffic patterns.
Query parameters:
UsageStatPoint):
Raw request logs
GET /api/v1/console/logs returns paginated individual request records for a key. Use this to debug a specific failure, audit what your application called, or investigate an unexpected 401.
Query parameters:
UsageLogEntry):
To page through results, increment
offset by your limit value on each request until offset >= meta.total.
How to find your API key UUID
Theapi_key_id parameter is the UUID assigned to your key at creation — not the key itself. To retrieve it, call the list keys endpoint:
id field in each object is the UUID you pass to the stats and logs endpoints.
Practical tips
Track your error rate over time. Use the daily stats withlimit=30 to build a 30-day view of error_calls / total_calls. A sudden increase often signals a breaking change in your integration or a rate limit being hit (429 in the raw logs).
Identify slow endpoints. The unique_endpoints field in stats tells you how many different paths were called in a period. When p95_latency_ms spikes, drill into raw logs filtered around that time window to see which endpoint is responsible.
Monitor quota usage. Compare total_calls against your key’s rate_limit (visible from the list keys response, in requests per minute). If you are regularly hitting your limit — indicated by 429 status codes in the logs — consider requesting a higher rate limit when creating a new key.
Use hourly granularity for active debugging. When investigating an incident from the past few hours, switch to granularity=hourly and limit=24 to see per-hour breakdowns instead of daily aggregates.