project · 2022-2024
Developer-portal analytics APIs
REST API layer that powers the analytics dashboards on developer.tomtom.com. Sits on top of an Azure Data Explorer (Kusto) backend that ingests every API call across TomTom's developer products. Volume reports, response-time percentiles, error-rate breakdowns, and per-product usage all flow through this layer.
The REST API layer that the live analytics dashboards on developer.tomtom.com consume to render a customer’s API usage. Built as the structured query interface in front of an Azure Data Explorer (Kusto) cluster that ingests every API call passing through the developer-product gateway.
What it does
Exposes a typed HTTP API for things the dashboard needs every page load:
- Volume reports: API calls per day / week / month, broken down by product, endpoint, and customer.
- Response-time percentiles: p50, p90, p95, p98, p99 latencies per product.
- Error breakdowns: 4xx vs 5xx by endpoint and time window.
- Quota and credit tracking: per-customer consumption against their plan.
- Per-parameter usage: which request shapes are most common per endpoint, useful for both customer support and product planning.
Every endpoint is paginated, rate-limited, and authenticated against the developer-portal SSO.
Why a service layer instead of querying ADX directly
The dashboards could in principle execute KQL queries from the browser. They do not, because:
- KQL leaks schema. A directly-queryable analytics store leaks every column, every table, every relationship to the frontend. The API layer narrows that to a typed contract the dashboard depends on.
- Query cost is unpredictable. A misformed KQL from an over-zealous frontend dev can scan terabytes. The API layer constrains queries to a known set of patterns with bounded scan costs.
- Aggregation and caching live here. Common queries (last-30-day volume per product) are cached at the API layer with TTLs tuned to how often the underlying data changes.
- Tenant isolation is enforced server-side. Customer X cannot see Customer Y’s data because the API layer filters every query by the authenticated tenant before issuing the KQL.
Stack
- Python FastAPI for the REST surface, async throughout for streaming KQL responses.
- Azure Data Explorer (Kusto) as the backing store, billions of rows partitioned by ingest time + tenant.
- OAuth + tenant scoping at every endpoint.
- OpenAPI spec auto-generated; consumed by the developer-portal frontend to type its query layer.
Why this earns a spot in projects
Most data-engineering work is invisible. This one is not. Every chart on the developer-portal analytics page is a request to an endpoint I built. Customers see the latency percentiles, plan their usage against the volume reports, and debug their integrations from the error breakdowns. The code is internal, but the impact is one click away on the public site.