Skip to main content
Arbitrage provides two endpoints for understanding how your API keys are being used: an aggregated statistics endpoint that groups calls into time periods, and a raw log endpoint that lets you inspect individual requests. Both require your console session token and the UUID of the API key you want to inspect. You can find the UUID in the list keys response.

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:
Response:
Response fields (UsageStatPoint):
Calculate your error rate as error_calls / total_calls. If this ratio rises above your baseline, check the raw logs to identify which endpoint is failing and what status codes are returned.

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:
Response:
Response fields (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

The api_key_id parameter is the UUID assigned to your key at creation — not the key itself. To retrieve it, call the list keys endpoint:
The 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 with limit=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.