API traffic monitoring, one request at a time.
Every request your API serves, recorded with its payload, its timing and its verdict, grouped by endpoint and watched for errors, slowdowns, breaking changes and abuse.
What is API traffic monitoring?
API traffic monitoring is recording the requests an API serves (who called which endpoint, with what payload, how long it took and what came back) and watching that traffic for errors, slowdowns, breaking changes and abuse.
Uptime checks
Tell you an endpoint answered a synthetic request. They never see the requests real customers sent, or what came back.
Logs
Record what your code chose to write down, one line at a time, usually without the payload. Reconstructing a request means searching for its pieces.
Traditional APM
Explains where time went inside a request, usually from a sample of traces, built around services and spans rather than around each API call and its consumer.
API traffic monitoring
Records every request as one whole: who called which endpoint, with what payload, how long it took and what came back, and watches that traffic for change.
Six things to monitor in your API traffic
Status pages and averages say whether the API is up. These say whether it is working for the people calling it.
Volume per endpoint
Requests per minute for each endpoint, not each URL, so /orders/{id} is one line on the chart and a sudden drop or surge stands out.
Error rates
Server errors, and client errors spread across many consumers, which point at your API rather than at one caller sending bad requests.
Latency percentiles
p95 and p99 per endpoint. An average hides the slow tail your customers actually feel.
Payload changes
A field removed or retyped in a response breaks clients before any error rate moves. Watching the payloads catches it.
Who is calling
Which customer, key or tenant sent each request, so you can tell one noisy integration from a problem everyone has.
Bots and abuse
Scrapers, credential stuffing and enumeration all arrive as ordinary-looking requests. Watching who sends what, and how often, is how they surface.
One record per request, from one install
ApiTraffic captures each request as one record: the payload in and out, every query and outbound call it caused, and the firewall's verdict. Requests group by endpoint automatically, so percentiles and error rates line up per route without annotating anything.
- Node.js: one SDK for Express, Fastify, NestJS and the rest, mounted where your framework expects it
- Any other stack: a proxy URL, your API address with only the hostname changed
- Search by anything - endpoint, status, duration, header, tag or a field in the body
Monitoring that knows your normal
Each endpoint is compared with its own baseline, and one incident opens per real problem, routed to Slack, email, PagerDuty, Jira or a webhook. Drift detection flags a removed or retyped field, and release markers show which deploy changed what.
See alerts & drift →- Asynchronous, batched delivery - nothing blocks your handler
- Credential headers and secret-looking keys masked before anything is sent
- Fails open: if ApiTraffic is unreachable, your API carries on
- An in-app firewall that reads the same requests it records
API traffic monitoring questions
API traffic monitoring is recording the requests an API serves (who called which endpoint, with what payload, how long it took and what came back) and watching that traffic for errors, slowdowns, breaking changes and abuse.
Traditional APM explains where the time went inside a request, usually from a sample of traces. API traffic monitoring keeps every request with its payload and its consumer, groups it by endpoint, and watches the traffic itself for errors, latency and changes. ApiTraffic does both from one install, with no sampling: each request record carries its queries and outbound calls.
No. ApiTraffic records traffic from inside your Node app with one SDK, or, for any other stack, through a proxy URL that is your API address with only the hostname changed. There is no gateway, agent or sidecar to run.
Yes. Generate a proxy URL for your bucket and send calls to it instead of your API address: they pass through ApiTraffic and land in your request log, grouped by endpoint and watched for incidents, from any language. The firewall and per-query performance data need the SDK.
Not with the SDK. It records each request in-process and returns immediately, then sends payloads in batches in the background, so no network call to ApiTraffic happens between your handler and your response. If ApiTraffic is unreachable, your API keeps serving requests.
Cloudflare decides whether a request gets in. We record what happened after it did.
Those are different jobs, and the gap between them is where most API incidents live. Your edge sees strangers - unknown IPs, bad signatures, known-bad patterns - and it’s good at that. What it can’t see is a legitimate, authenticated key behaving unlike itself: enumerating IDs one at a time, pulling fifty times its normal volume on a Sunday, or walking endpoints it has never touched before. That traffic passes every edge check, because it’s a customer.
Keep Cloudflare. We’re the layer inside your app where the caller has a name, a history, and a bill.
Datadog is a much broader product. If you need to monitor a Kafka cluster, build custom dashboards for forty services, and correlate across your whole estate, use Datadog - we’re not that, and we’re not trying to be.
We answer one question well: who called your API, and what happened. Because logging, timing, and screening run in one middleware, you get one record per request with the trace and the security verdict already on it. Nothing to correlate by request ID across three products and three clocks at 2am.
The other difference is structural. There’s no host agent to deploy, so there’s no per-host meter and no bill that grows every time you add a container.
What we don’t do: infrastructure monitoring, RUM, log ingestion from things that aren’t your API, or 800 integrations.
No. The middleware fails open.
If our collector is unreachable, requests complete exactly as they would without us. Telemetry queues into a bounded in-memory buffer and is dropped once that buffer is full - it never grows without limit, and it never blocks a response. You lose visibility for the duration of the outage. You don’t lose traffic.
Enforcement is a separate question, and the answer is better than fail-open usually implies. Verdicts are evaluated in your process against the policy you last synced, not by calling us - so a rule that was live when the connection dropped is still live now. During an outage you stop receiving policy changes; you do not stop being protected. The kill switch works the same way: API_TRAFFIC_WAF_ENABLED=false takes effect without a deploy and without reaching us, which is the case that matters when we are the problem.
Yes, through the proxy URL - and the SDKs are Node because that is where we can go deepest.
For any other stack, generate a proxy URL for your bucket: the same URL as your API call with only the hostname changed. Calls sent through it land in your request log, searchable, grouped by endpoint and watched by alerting, from any language and with no code to install.
The SDKs add what only an in-process middleware can see: your route definitions (/users/:id as one endpoint instead of forty thousand paths), the outbound calls your app makes, the queries behind each request, and a firewall that inspects the parsed request. That is why the first-party SDKs are for Node frameworks.
You decide what is kept, and the secrets are masked before you configure anything.
From the very first request, credential headers - Authorization, cookies, API key and CSRF headers - and secret-looking keys in bodies and query strings are masked inside your process, before anything is sent.
On top of that, redaction rules mask your own fields, either in your app so the value never leaves your server or on our side just before storage. Exclusion rules keep a route out entirely, or log its requests without their bodies. Everything you see afterwards - the request log, share links, embeds, the API and the MCP server - sees only the redacted value.
Keep them. Application logs are what your code chose to say. We record what actually crossed the wire.
The difference shows up on the requests you didn’t write a log line for: the ones that 404’d before reaching a handler, the ones that failed auth, the ones hitting a route someone shipped last quarter and forgot. Those don’t appear in your app logs precisely because your code never ran - and they’re disproportionately the ones worth looking at.
There’s also no correlation step. The timing and the verdict are already on the record; you’re not grepping a log drain and joining it to something else by hand.
The middleware is public on GitHub if you’d rather read it than take our word for what it does on the request path.
ApiTraffic tells you - alerts are on every plan.
Every endpoint is compared with its own normal, and a change has to be a multiple of normal, big in real terms and statistically real before anyone is told. Related alerts become one incident, sent to Slack, email, PagerDuty, Jira or a webhook following your routing. Drift detection adds breaking API changes, and deploy markers let you see which release changed what. How alerting works
Know what your API did - before your customers tell you.
One npm install and one line of code. Your first requests arrive in minutes, with their queries, their firewall verdict and a baseline for every endpoint already building.
Free trial · No credit card · Set up in minutes