Simple pricing. Every number on the page.

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.

Fair question, and the right one to ask about middleware in a single-threaded runtime.

Nothing that matters runs on your request path. We capture metadata in-process, hand it to a buffer, and ship batches asynchronously off the event loop. No network call, no serialisation of large payloads, and no synchronous work between your handler and the response.

Don’t take our word for it: the middleware is public on GitHub, so you can read exactly what runs on your request path - and measure it against your own service on staging before it goes anywhere near production.

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.

For as long as your plan’s retention window, and no longer. Each plan’s window is listed on the pricing page. Captured bodies and APM spans are separate entitlements with their own windows, so the most sensitive data can expire well before the request metadata does.

When an account is closed, its telemetry is deleted. Data is encrypted in transit and at rest, and only the sub-processors described in our privacy policy ever handle it - email us for the current list.

You hear from us before it happens, and the plan says exactly what happens next.

We email you when an allowance reaches 80% and again at 100% - once each per billing period, so it is a warning rather than noise. Past the allowance, each plan either meters the extra at a published rate or stops at the limit; the pricing table shows the rate wherever one applies. Nothing is billed at a price that isn’t on that page.

If you’re running a formal API security programme with a dedicated team, buy a dedicated tool. We’d tell you the same thing on a call.

For everyone else, the advantage isn’t rule count - it’s that the verdict lives on the same record as the trace. When something gets blocked, you can find every other request from that caller in one click, decide whether the block was right, and change the rule. When something isn’t blocked but looks wrong, you have the evidence to say so. Most teams don’t lose to a missing rule; they lose to not knowing what happened.

What ships out of the box: managed detection for the OWASP injection families - SQLi, XSS, RCE, path traversal, SSRF, SSTI, NoSQL injection and XXE - with CRS-style anomaly scoring and paranoia levels, IP and geo lists, structural request limits, per-instance rate limiting - each server enforces the limit on the traffic it receives - and behavioral protection, which scores callers across requests and pushes a temporary deny to every server. Policies are authored in ApiTraffic and pushed to every connected server.

What it does not do, because it runs inside your app: absorb a volumetric DDoS - by the time a request reaches middleware it has already cost you a connection, so keep your edge for that - or issue JavaScript and CAPTCHA challenges to tell browsers from bots. It only sees traffic that reaches your Node process.

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

Yes. For custom request allowances, longer retention, annual invoicing or a security review, talk to us and we will put together a plan that fits.

Yes. Every account has a referral link under Account → Referrals. When someone signs up through it, you can both earn rewards - extra allowances or plan features for a set time, depending on the promotion that is running. Rewards are applied automatically and never take anything away from your plan.