API Analytics 101: What to Measure and Why
API analytics tells you who uses your API, which endpoints struggle, and where errors spike. The metrics that matter and how to start collecting them.
If you ship an API, your API is a product - and most teams know less about how it's used than about any other product they own. Which endpoints carry the load? Who are the heaviest consumers? Where do errors actually happen? API analytics answers those questions, and it takes less instrumentation than you'd think.
The metrics that matter#
Request volume by endpoint. The shape of your traffic. Almost always a power law - a few endpoints carry nearly everything - which tells you where optimization and caching effort pays off.
Latency percentiles, not averages. p50, p95, p99 per endpoint. Averages hide tail latency; a p99 of 8 seconds means one in a hundred users has a terrible experience even when the average looks fine.
Error rate by status class. 4xx and 5xx rates per endpoint, separately. A 5xx spike is your bug; a 4xx spike on one endpoint is often a confused integration or a breaking change someone didn't notice.
Usage per consumer. Requests grouped by API key or account id. This finds your power users, your abusers, and the customer silently hammering a deprecated endpoint you want to retire.
Why server logs alone aren't enough#
Your servers already emit access logs - but raw logs answer "what happened," not "what's the trend." The questions above are all aggregations: counts, percentiles, and group-bys over millions of requests. That requires your request events in a queryable store, not scattered across log files. This is the same reason columnar databases beat search indexes for log analytics, as we covered in ClickHouse vs Elasticsearch.
The instrumentation is one event per request#
Log a single JSON event per request from middleware:
{
"event": "api_request",
"route": "/v1/charges",
"status": 200,
"latency_ms": 87,
"account_id": "acct_1234"
}
One POST to GraphJSON's log API and every metric above becomes a query - percentiles and group-bys included. Our SQL cheat sheet has the patterns, and querying JSON in ClickHouse covers the extraction functions behind them.
Alert on the tails and turn it into a feature#
Two follow-ons once the data flows. First, alert on p99 latency and 5xx rate per endpoint - that's how you learn about incidents before your status page does. Second, remember that your customers want this data too: usage dashboards per account are a genuine product feature, and embedded dashboards with per-request filters let each customer see exactly their own slice.
Written by JR
Founder and builder of GraphJSON.
