API Analytics: What to Measure and What the Numbers Mean

Treblle's platform handles 3 billion API requests and 9 terabytes of data each month. The data comes from production APIs across thousands of organizations, not from surveys or synthetic traffic. That volume generates a specific picture of what teams actually measure, what they ignore, and where the mismatch happens.

Most teams measure API calls. Total requests per day, requests per endpoint, error rates. These numbers answer one question: Is the API running? They don't answer the questions that drive product decisions: which consumers are growing, which endpoints are being abandoned, which latency trends predict churn before the consumer leaves.

API analytics is the practice of measuring what the traffic data actually tells you, beyond whether the lights are on. This article covers the four measurement dimensions that matter, what each reveals, and how to connect the data to decisions.

What API analytics actually tells you (beyond call counts)

A raw call count (4.2 million requests today) answers whether the API is being used. It doesn't answer who is using it, how they're using it, whether usage is healthy or symptomatic, or how usage is changing over time.

The meaningful analytics come from looking at that number across four axes:

• By consumer. The same 4.2 million requests look very different if they come from 50 consumers with stable growth patterns versus 3 consumers accounting for 95% of traffic and 47 consumers who haven't called the API in two weeks.
• By endpoint. High-call endpoints reveal what consumers actually value. Zero-call endpoints are zombie candidates: endpoints that stay live and expand attack surface without providing value. Endpoint distribution also reveals undocumented usage patterns: consumers using endpoints in sequences the design didn't anticipate.
• By outcome. Error rates per endpoint, error rates per consumer, and error rate trends over time tell you whether the API is degrading or improving and where the degradation is concentrated.
• By time. Usage patterns over 24 hours, week-over-week trends, and month-over-month growth. Time-series data distinguishes healthy growth from volatile usage that may indicate consumer-side issues, attack traffic, or a consumer testing an automated workflow.

The difference between a monitoring dashboard and an analytics system is what question each answers. Monitoring answers, "Is something wrong right now?" Analytics answers, "How is this changing, and what should I do about it?"

Consumer analytics: who is calling your API and how

Consumer analytics is the most underutilized dimension of API data, and the one with the highest signal density for product decisions.

Most APIs have a consumer distribution that looks roughly like this: a small number of high-volume consumers account for a large share of traffic, a long tail of low-volume consumers generates the remainder, and some portion of provisioned consumers has called the API zero times in the measurement window. The shape of this distribution, and how it changes over time, tells you more about product-market fit, adoption friction, and integration health than any aggregate metric.

Geographic distribution reveals where the actual user base is concentrated versus where the intended market is. When an API designed for US enterprise customers draws 60% of its traffic from Europe, the pattern may indicate untargeted adoption or a gap in the US marketing motion. Geographic data also surfaces security signals: a consumer whose traffic suddenly shifts geographic origin is a potential account takeover indicator.

Client type and SDK distribution shows which integration patterns consumers are using. A server-side SDK indicates a team building the production integration. A direct HTTP client suggests a simpler or exploratory integration. A mobile client with no corresponding web client may indicate a mobile-first consumer segment the team hadn't prioritized. The client distribution shapes documentation strategy: consumers using an SDK need different documentation than consumers making raw HTTP calls.

Time to First Hello World (TTFHW) is the interval between a consumer's first API key provisioning and their first successful API call. Treblle tracks TTFHW as a leading indicator of documentation quality and developer experience. A long median TTFHW signals that consumers are hitting friction in the integration path before they even make their first call. The metric predicts adoption rates: consumers who don't make a successful call quickly are disproportionately likely to abandon the integration.

Churn signals are the patterns that precede a consumer going quiet. These leading indicators show that a consumer is having trouble and hasn't yet asked for help: a drop in call volume from a previously active consumer, an uptick in error rates for a specific consumer, a shift from production traffic to sandbox traffic. Identifying them early creates an opportunity to intervene that post-churn analysis doesn't.

Treblle's Consumer Analytics tracks per-consumer data across call volume, geographic origin, client type, error rate, and request patterns. This consumer-level decomposition turns aggregate traffic data into product and success signals.

Endpoint-level usage: finding unused endpoints before they become zombie APIs

The zombie endpoint problem is measurable. In Treblle's 2025 traffic data, 17% of all tracked endpoints are zombie APIs: live, accessible, and receiving no legitimate production traffic. Industry-wide measurement shows the problem growing: the zombie share rose from 24% in 2023 to 35% in 2024.

Zombie endpoints are an analytics problem before they become a security problem. The data that identifies them is available in endpoint-level usage metrics: zero or near-zero call volume for a sustained period. Teams usually know their zombie endpoints exist. They don't decommission them sooner because they lack confident data on whether any consumers depend on them.

Endpoint-level analytics makes decommissioning decisions data-driven:

• Zero-call endpoints with no traffic in 90 days are zombie candidates. If no consumer is calling them, decommissioning has no impact on consumers. Confirm with a last-active timestamp; an endpoint designed for a quarterly batch process that ran last month is not a zombie endpoint.
• Declining-call endpoints show traffic trending toward zero. Consumers may be abandoning them as they migrate to a newer version. Catching this trend before traffic reaches zero lets the team communicate the deprecation proactively rather than decommission reactively.
• High-call endpoints with high error rates are the inverse problem: actively used endpoints that are failing a significant portion of the time. Investigate these before the consumer notices and files a support ticket.
• Endpoint distribution skew (a small number of endpoints receiving a disproportionate share of traffic) reveals which parts of the API surface are actually providing value versus which were built on spec but aren't being used. For prioritizing the roadmap, this data is more reliable than stakeholder opinion.

POST requests surged 80% in 2025 and now account for 43% of all API traffic. If an analytics system tracks only call counts without method distribution, it misses the shift toward write-heavy API usage. Write-heavy traffic has a different security and performance profile than the read-heavy patterns that predominated earlier.

Treblle's Real-Time Request Explorer captures every request at the endpoint level (method, status, consumer, latency, payload) without sampling. The usage data reflects what's actually happening rather than a statistical estimate derived from a sample.

Performance analytics: latency trends over time

Latency is the performance metric consumers feel directly, and the one most likely to drive churn before a consumer explicitly complains about it. When a consumer sees p95 latency climb from 200ms to 800ms over a month, they will typically integrate a competitor's API before they file a support ticket.

Three latency metrics matter:

p50 (median latency). The latency experience for the typical request. Useful for understanding baseline performance. Not useful for identifying tail latency problems because the median masks the distribution.

p95 latency. The latency threshold that 95% of requests complete within. This metric shows what most consumers experience in practice, including during moderate load. A p95 that's 10x the p50 indicates significant tail latency: a minority of requests much slower than typical, often driven by specific endpoint patterns, consumer behaviors, or infrastructure contention.

p99 latency. The threshold for the slowest 1% of requests. Relevant for SLA definitions and for identifying the worst-case consumer experience. High p99 latency often indicates a specific class of requests (large payloads, complex queries, cold-start infrastructure) that needs a different handling strategy.

Tracking these percentiles over time, rather than as point-in-time measurements, makes them actionable. When a p95 has been stable at 180ms for three months and then climbs to 420ms in a week, it has a specific cause: a deployment, a configuration change, a shift in traffic distribution. When a p95 drifts slowly upward over six months, it reflects structural degradation that requires a different response.

Treblle's Latency Percentiles track p50, p95, and p99 per endpoint over time. This surfaces regressions and drift without requiring manual queries across log infrastructure.

API analytics for product decisions

The end state of API analytics is product decisions: what to build, what to deprecate, what to invest in, what to shut down. The measurement dimensions above each feed a specific class of decision.

What to deprecate: Zero-call endpoint data identifies zombie endpoints for decommissioning. Declining-call data identifies routes that consumers are abandoning. Consumer migration data (consumers moving from v1 to v2 endpoints) identifies when old versions have low enough adoption to sunset safely.

What to prioritize: High-call endpoint data reveals what consumers actually value, often different from what the roadmap assumed. Consumer growth data identifies which consumer segments are expanding fastest and may warrant dedicated features or integrations.

What to fix: High-error-rate endpoint data identifies reliability problems before consumers escalate. Latency regression data identifies performance degradation in its early stages rather than after consumers have churned. TTFHW data identifies documentation and onboarding friction that's suppressing adoption.

What to monetize: Usage data is the prerequisite for any consumption-based pricing model. Metering requires accurate per-consumer, per-endpoint call counts. Tier design requires understanding the actual usage distribution: where the natural usage breaks are in the consumer population.

The governance dimension connects analytics to portfolio management: endpoint usage data feeds the zombie endpoint identification that drives API catalog hygiene; consumer analytics feeds the API adoption metrics that demonstrate platform ROI to leadership. The API governance framework and API discovery guide cover how analytics integrates into the broader governance and discovery workflows.

In full-stack API observability, analytics is one layer alongside security monitoring and performance alerting. The API observability guide covers how the layers fit together.

API monetization: how analytics enables pricing models

Monetizing an API requires answering one question accurately: how much value is each consumer extracting, and can that value be measured in a way that maps to a billing unit? Analytics is how you answer it.

The three primary consumption-based billing models each require specific analytics capabilities:

• Pay-per-call meters individual API requests. It's the simplest model to implement and the most granular. But it's often a poor fit for consumer behavior: price-sensitive consumers will batch requests or reduce usage in ways that cut the value they get from the API. Analytics reveals the actual request patterns that make per-call pricing viable or problematic for specific consumer segments.
• Tiered pricing defines usage brackets with a flat fee per tier. It requires analytics that show where natural usage breaks exist in the consumer population. A tier boundary at 10,000 requests/month makes sense if there's a natural gap in consumer usage between 8,000 and 12,000 requests. It doesn't make sense if the distribution is continuous. Usage distribution data makes tier design empirical rather than arbitrary.
• Outcome-based pricing charges for a specific result (a successful transaction, a completed authentication, a delivered notification) rather than for API calls. It requires analytics that track outcomes: not just that the API was called, but that the call achieved its intended business outcome. Error analytics is the prerequisite: you can only bill for successful outcomes if you can distinguish them from failures at scale.

Treblle's Zero-Sampling Ingestion captures every request at any traffic volume. Complete capture is the prerequisite for metered billing accuracy: a billing system built on sampled data has statistical error; a billing system built on complete data has exact counts.

How Treblle helps

Consumer Analytics. Per-consumer data across call volume, geographic origin, client type, error rate, and request patterns. Tracks TTFHW (Time to First Hello World) as a developer experience metric. Surfaces churn signals (declining volume, rising error rates, behavioral shifts) before consumers reach out or abandon the integration.

Latency Percentiles (p50/p95/p99). Per-endpoint latency distribution tracked over time. Surfaces tail latency and regression without requiring manual log queries. Makes the difference between knowing latency is bad and knowing which endpoints degraded, when, and by how much.

Error Analytics. Error rates broken down by endpoint, status code, consumer, and time period. Identifies recurring failure patterns and distinguishes consumer-side errors from API-side errors, a distinction that aggregate error rates erase.

Real-Time Request Explorer. Full-fidelity capture of every request: endpoint, method, consumer identity, response, latency. No sampling. The basis for endpoint-level usage analytics and the investigation tool when a metric anomaly requires root cause analysis.

Zero-Sampling Ingestion. Full capture at 10,000 RPS with under 0.1ms ingress latency. The prerequisite for accurate metered billing, complete zombie endpoint identification, and usage analytics that reflects actual traffic rather than statistical estimates from sampled data.

Treblle connects from a single SDK integration and starts measuring your API analytics baseline: call volume by consumer, endpoint usage distribution, and latency percentiles across your portfolio.