# api-analytics: hosted API monitoring across many frameworks

> api-analytics is a monitoring service for HTTP APIs that reaches your application through a thin per-framework middleware, covering Python, JavaScript, Go, Rust, Ruby, PHP and C#. The data goes to a hosted dashboard rather than to a database you own, and that is the trade-off every section of the documentation points at.

**tom-draper/api-analytics** — Effortless monitoring and analytics for API frameworks.

- Repository: https://github.com/tom-draper/api-analytics
- Website: https://apianalytics.dev
- Stars: 653 · Forks: 69
- Language: Go
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tom-draper-api-analytics

## One idea, seven language ecosystems

api-analytics is described as a low friction analytics solution for API frameworks, complete with a dashboard, and the compatibility list is the clearest statement of its scope.

For Python it covers FastAPI, Flask, Django and Tornado. For JavaScript it covers Express, NestJS, Hono, Fastify, Koa and Elysia. For Go there is Gin, Echo, Fiber and Chi, for Rust Actix, Axum and Rocket, for Ruby Rails and Sinatra, for PHP Laravel and native PHP, and for C# ASP.NET Core.

That breadth is the point of the design. The idea is that a team running a polyglot estate should not have to learn a different analytics product per language, and that the shape of the integration should be identical everywhere, which is why every example in the README is the same three lines: import, attach the middleware, and carry on with your routes.

The mechanism is deliberately thin. The README says that since most data processing is handled by the API Analytics server, the middleware has minimal impact on the API's performance. In other words, the client library does little more than observe the request and report it, and the aggregation happens elsewhere.

The primary language of the repository is Go, which is a sensible choice for a service that has to receive events from clients written in a dozen ecosystems.

## A key, a hosted dashboard, and data leaving your process

The getting started section has two steps, and the first one is worth reading carefully for what it implies about the data flow.

You generate a unique API key with a single click at apianalytics.dev/sign-up. The README says this key is used to monitor your specific API, that it should be stored privately, and that it is required when accessing your API Analytics dashboard and logged data. So the key has two jobs: it identifies the API being monitored in the service, and it authenticates you when you come back to look at the results.

The second step is adding the lightweight middleware to your API.

The important architectural fact is that this is a client reporting to a hosted server. Your request metadata leaves the process, crosses the network and lands in someone else's infrastructure, where the dashboard is served from apianalytics.dev. The README presents this as a feature, since it is what makes the middleware negligible, but it is also the constraint to weigh before you install it.

For a team handling production traffic with authentication headers, personal data or internal hostnames in the requests, that is a decision to make deliberately rather than by default. The middle ground is to know which fields the middleware sends, and the README does not document that, so it is a question to ask before a first deployment rather than after.

## The FastAPI path, from install to a working app

The Python packages are published on PyPI as api-analytics with per-framework extras, and the FastAPI example is the shortest of them.

The install command selects the framework integration:

```bash
pip install api-analytics[fastapi]
```

And the application code is the middleware plus your routes:

```py
import uvicorn
from fastapi import FastAPI
from api_analytics.fastapi import Analytics

app = FastAPI()
app.add_middleware(Analytics, api_key="YOUR-API-KEY")  # Add middleware

@app.get('/')
async def root():
    return {'message': 'Hello, World!'}

if __name__ == "__main__":
    uvicorn.run("app:app", reload=True)
```

The comment on the middleware line says it all: Add middleware. Everything else in the file is an ordinary FastAPI application, and the SDK is imported from the api_analytics.fastapi namespace so the framework specific module is explicit.

Flask follows the same pattern with a helper rather than a class, pip install api-analytics[flask] and then add_middleware(app, "YOUR-API-KEY") imported from api_analytics.flask. The API key is passed as a keyword argument in the FastAPI case and positionally in the Flask case, which is a small inconsistency but a trivial one to work around.

## The same three lines in Express, Gin and Actix

Looking at the JavaScript, Go and Rust examples together makes the design clearer, because the shape of the integration is identical even though the idiom is not.

In Express the package is installed from npm and the middleware is a function:

```bash
npm install @api-analytics/express
```

```js
import express from 'express';
import { expressAnalytics } from '@api-analytics/express';

const app = express();

app.use(expressAnalytics("YOUR-API-KEY")); // Add middleware
```

In Go the module is fetched with go get and the middleware is registered on the router:

```bash
go get -u github.com/tom-draper/api-analytics/analytics/go/gin
```

In Rust the crate is added with cargo add, and the middleware is a layer wrapped around the application:

```bash
cargo add actix-analytics
```

The three integrations are the same three steps: install the framework specific package, pass the API key, and register the middleware in the place that framework expects. There is no configuration file, no collector to run, and no SDK to initialise, which is what makes the promise of drop in support plausible rather than aspirational.

The per-framework packages are published to the ecosystem registries: the JavaScript ones to npm, the Python one to PyPI, the Rust ones to crates.io, the Ruby one as a gem, and the Go one as a module path under the repository's analytics/go tree.

## Django wants a setting and a stack position

Django is the one integration in the README that does not fit the middleware as a single call, and the reason is structural rather than a quirk of the library.

Instead of a function call, the API key is assigned to ANALYTICS_API_KEY in settings.py, and the Analytics middleware is added to the top of the middleware stack:

```py
ANALYTICS_API_KEY = "YOUR-API-KEY"

MIDDLEWARE = [
    'api_analytics.django.Analytics',  # Add middleware
    ...
]
```

Two details are load bearing. The key lives in settings rather than in the middleware list, which is the Django convention for configuration and means it can be overridden per environment. And the position matters, since a middleware that only sees requests after another one has already handled them will miss traffic, so putting Analytics first means it observes the request before anything else in the stack can short-circuit it.

For an application with authentication in front of its routes, that ordering is what decides whether you see the traffic you expect to see. It is the kind of detail that is easy to get wrong and hard to notice, since a middleware that runs too late simply reports less.

## Three directories: clients, dashboard and server

The repository top level is small and splits the project into three parts: an analytics/ directory holding the per-language middleware, a dashboard/ directory, and a server/ directory.

That layout matches the architecture. The middleware packages are thin and mostly per-language, the server is where the events are received and processed, and the dashboard is the interface you look at. The primary language of the repository is Go, which is consistent with the server being the substantial part rather than the clients.

The project is MIT licensed, the homepage is apianalytics.dev, and the repository topics cover the full span of what it touches, from analytics and api-monitoring to dashboard, middleware, server-analytics and the list of framework names themselves, including a couple of package specific ones such as fastapi-analytics.

On maintenance, the last push to the repository was on 2026-10-13, and there are no GitHub releases, so the versioning and the changelog live with the service rather than with tagged artefacts in the repository. The CONTRIBUTING.md and LICENSE files at the root are the only other top level entries.

For anyone reading the code, the interesting question is what the middleware actually sends. The README documents the integration but not the payload, and the middleware directories are where that answer lives.

## When a hosted collector is the wrong shape

There is a version of this problem that api-analytics solves better than a self-hosted stack, and a version where it is the wrong answer.

The case for it is the polyglot estate. The client packages are thin, the language list is wide, and there is nothing to operate. For a team running a handful of services across several frameworks that nobody wants to maintain a telemetry pipeline for, a hosted collector with a dashboard is a reasonable trade, and the effort involved is one middleware line per service.

The case against it is a data residency requirement. The architecture is a client that reports to a hosted server, and if request metadata cannot leave your network, this product does not apply, and no amount of configuration will change that. A log pipeline into storage you own is the alternative in that case, with the cost that someone maintains the parsing, the dashboards and the retention, which is exactly the work the hosted service is selling.

The middle ground is worth thinking about explicitly. You can get the framework coverage without the hosted collector by using the same middleware packages to emit into a local pipeline, if the packages allow it, or by writing the same three lines against an internal collector. The README does not describe that path, so anyone planning to move later should read the middleware source before committing.

There is also the question of what the key is worth. A key that identifies a monitored API and grants access to its logged data is a credential for your traffic history, and it is a credential that lives in a service outside your infrastructure, which is a fact to weigh alongside the convenience.

## Conclusion

Adopt api-analytics if you want request level visibility across a polyglot set of services without building a telemetry pipeline, and you are willing to send request metadata to a third party. Skip it if request data must stay inside your own network, since the architecture here is explicitly a client that reports to a hosted server, in which case a log pipeline into storage you control is the honest alternative. Before you wire it in, generate a key at apianalytics.dev/sign-up, keep it out of version control, and check the middleware ordering for your framework, since Django in particular requires the Analytics middleware at the top of the stack. The last push was on 2026-10-13, the licence is MIT, and there are no GitHub releases.

## FAQ

### Which frameworks does api-analytics support?

Python FastAPI, Flask, Django and Tornado; JavaScript Express, NestJS, Hono, Fastify, Koa and Elysia; Go Gin, Echo, Fiber and Chi; Rust Actix, Axum and Rocket; Ruby Rails and Sinatra; PHP Laravel and native PHP; and C# ASP.NET Core.

### How do I add api-analytics to a FastAPI application?

Install it with pip install api-analytics[fastapi], then add the middleware with app.add_middleware(Analytics, api_key="YOUR-API-KEY"), importing Analytics from api_analytics.fastapi.

### How is api-analytics set up for Django?

Assign ANALYTICS_API_KEY in settings.py and add 'api_analytics.django.Analytics' to the top of the MIDDLEWARE list. The README specifies the top of the middleware stack.

### Where is the data collected by api-analytics sent?

Most data processing is handled by the API Analytics server, and the dashboard and logged data are reached through apianalytics.dev using the API key generated at apianalytics.dev/sign-up. The middleware is therefore a client that reports to a hosted service.

## Sources

- [Issues](https://github.com/tom-draper/api-analytics/issues)
- [License: MIT](https://github.com/tom-draper/api-analytics/blob/main/LICENSE)
- [Project website](https://apianalytics.dev)
- [README](https://github.com/tom-draper/api-analytics/blob/main/README.md)
- [tom-draper/api-analytics on GitHub](https://github.com/tom-draper/api-analytics)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tom-draper-api-analytics