POST /v1/events from your API middleware · open source (MIT) · ask in plain English

Add analytics to your API product API products.

API product analytics is entirely server-side. There is no page to tag, the whole product is requests, so the questions are time-to-first-call, which endpoints get adopted, and which keys are about to churn. smolanalytics ingests those from your backend over POST /v1/events, batched, so you get an activation and usage picture without bolting on a heavy metrics stack.

POST /v1/events from your API middleware
# in request middleware, keyed by the caller's account/key id:
curl -X POST https://YOUR-INSTANCE/v1/events \
  -H "Authorization: Bearer WRITE_KEY" \
  -d '{"name":"api_call","distinct_id":"acct_123",
       "properties":{"endpoint":"/v2/charges","status":200,"ms":48,"plan":"pro"}}'

# batch: POST an array of up to 10k events to save calls

No SDK: emit one event per request (or a batched array) from middleware, keyed by account or API-key id as distinct_id. Sample high-volume endpoints if needed and always record status so error rate is queryable.

how do I add analytics to api products?

API product analytics is entirely server-side. There is no page to tag, the whole product is requests, so the questions are time-to-first-call, which endpoints get adopted, and which keys are about to churn. smolanalytics ingests those from your backend over POST /v1/events, batched, so you get an activation and usage picture without bolting on a heavy metrics stack.

Track the developer lifecycle: key issued, first call, first successful call, second endpoint adopted, then sustained daily calls. Time-to-first-call is your activation metric and endpoint breadth predicts expansion, so tag every request with endpoint, status, latency, and plan. Now you can answer which endpoints drive adoption, which accounts hit errors right before they go quiet, and whether a given customer's usage is trending toward an upgrade or toward churn, per key, without a separate BI project.

The fit is that ingestion here is itself just an API: one authenticated POST /v1/events, batched to 10k, so instrumenting from middleware in any language is a few lines and won't add latency if you fire async. Because reports are deterministic and CI-proven, per-account usage numbers are safe to surface back to customers or to sales as expansion signals. Export is one curl to /v1/export as CSV or JSONL when you want the raw events in your warehouse.

Honest pricing: 14-day full trial, no credit card. Then Solo $29/mo, never metered on seats or sites. Overage is $5/million with an emailed receipt, the dashboard never locks, and self-hosting the single Go binary is free forever (MIT).

Add analytics to API products tonight.

One snippet, or one endpoint. Tomorrow morning the verdict tells you which part of the funnel to fix.

questions

How do I add analytics to API products?
API product analytics is entirely server-side. There is no page to tag, the whole product is requests, so the questions are time-to-first-call, which endpoints get adopted, and which keys are about to churn. smolanalytics ingests those from your backend over POST /v1/events, batched, so you get an activation and usage picture without bolting on a heavy metrics stack.
Do I need a cookie banner?
Not in cookieless mode. smolanalytics can run without storing anything on the device, so there is no consent banner to add. You still get visitors, referrers, funnels, retention, and paths, and AI-assistant referrals (chatgpt.com, claude.ai, perplexity.ai) show up as their own channel.
Is it enough for a real product, or just page counts?
It does funnels, retention, paths, cohorts, and a daily verdict on what to fix, from the same events, and you ask it in plain English. It deliberately skips session replay, feature flags, and experiments. If you want a straight answer on what to fix, that you own and can self-host free, it fits.

keep reading