DEV Community

Cover image for Stop Building API Dashboards From Scratch
Konstantin Kai
Konstantin Kai

Posted on

Stop Building API Dashboards From Scratch

Every API developer has been there. You ship an API, someone starts using it, and the questions begin:

  • "How many requests are we getting?"
  • "Who's our heaviest consumer?"
  • "Why did error rates spike at 3am?"

So you write a few SQL queries. Maybe stand up a Grafana instance. Add some log parsing. Before you know it, you've spent two days on infrastructure that has nothing to do with your actual product.

The pattern I kept repeating

For every API project, I built some version of the same system:

  1. Log request metadata to a database
  2. Write queries to aggregate it
  3. Build a dashboard to visualize it
  4. Set up alerts when things go wrong

The fourth time I did this, I realized it should be a product.

PeekAPI: one middleware call, full API analytics

PeekAPI is a middleware you add to your API server. Here's the full setup:

Node.js (Express):

import { peekapi } from "@peekapi/sdk-node";
app.use(peekapi({ apiKey: "pk_..." }));
Enter fullscreen mode Exit fullscreen mode

Python (FastAPI):

from peekapi import PeekAPIMiddleware

app.add_middleware(PeekAPIMiddleware, api_key="pk_...")
Enter fullscreen mode Exit fullscreen mode

Go (net/http):

handler := peekapi.Middleware(mux, peekapi.Config{
    APIKey: "pk_...",
})
http.ListenAndServe(":8080", handler)
Enter fullscreen mode Exit fullscreen mode

Rust (Actix Web):

App::new()
    .wrap(PeekApi::new("pk_..."))
    .service(/* your routes */)
Enter fullscreen mode Exit fullscreen mode

Ruby (Rails):

# config/application.rb
config.middleware.use PeekAPI::Middleware, api_key: "pk_..."
Enter fullscreen mode Exit fullscreen mode

PHP (Laravel):

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->append(\PeekAPI\Laravel\PeekApiMiddleware::class);
})
Enter fullscreen mode Exit fullscreen mode

Java (Spring Boot):

# application.properties
peekapi.api-key=pk_...
Enter fullscreen mode Exit fullscreen mode

That's the entire integration for each language. No agents, no config files, no infrastructure to manage.

What you get

Once the middleware is running, your dashboard shows:

Real-time request stream — every API call as it happens, with method, path, status, latency, and consumer identity.

Endpoint analytics — request volume, error rates, and average latency for each route. Spot which endpoints are most used, which are failing, and which are slow.

Consumer tracking — PeekAPI automatically identifies who's calling your API from authorization headers or API keys. Consumers are identified by a SHA-256 hash — raw credentials never leave your server.

Smart alerts — get notified when error rates spike, latency exceeds thresholds, or an endpoint goes silent. Notifications via email, Slack, Discord, Telegram, or generic webhook.

What it captures (and what it doesn't)

Captures: HTTP method, path, status code, response time, request/response size, and a hashed consumer identifier.

Does NOT capture: request/response bodies, query parameters, or raw authentication credentials.

This is a deliberate design choice. PeekAPI answers "who, what, when, how fast" — not "what data was in the request." If you need payload inspection, you need a different tool.

Zero dependencies, by design

Every SDK is zero-dependency. The Node SDK uses only built-in modules (https, crypto, fs, os). Python uses only stdlib. Same for Go, Rust, Ruby, PHP, and Java.

Why? Two reasons:

  1. No supply chain risk. Your API middleware shouldn't pull in a tree of transitive dependencies.
  2. No conflicts. The SDK will never clash with your existing dependency versions.

Built for reliability

The SDKs are designed to never affect your API's performance or reliability:

  • Async buffering — events are collected in memory and flushed in batches (configurable interval and batch size)
  • Exponential backoff — if the analytics server is down, the SDK backs off automatically (max 5 consecutive failures)
  • Disk persistence — after max flush failures, on non-retryable errors, or on process shutdown, undelivered events are saved to a JSONL file. Recovered automatically every 60 seconds and on startup
  • Graceful shutdown — SIGTERM/SIGINT handlers persist buffered events to disk, recovered automatically on restart

If PeekAPI's servers are unreachable, your API keeps running normally. Analytics are best-effort — they should never be a single point of failure.

7 SDKs, 18+ frameworks

Language Frameworks
Node.js Express, Fastify, Koa, Hapi, NestJS
Python ASGI, WSGI, Django
Go net/http, Gin, Echo, Fiber, Chi
Rust Actix Web, Axum, Rocket
Ruby Rack, Rails
PHP PSR-15, Laravel
Java Spring Boot, Jakarta Servlet

Try it

Free tier at peekapi.dev — 500K events/month, no credit card required. SDKs are MIT licensed.

If you have questions about the architecture or feature requests, I'd love to hear them in the comments.

Top comments (0)