Itnetic TechnologiesOur core defense is a browser challenge — an interstitial that runs a little JavaScript and hands back a signed cookie. A real browser solves it instantly. curl, an SDK, a mobile app or a webhook cannot solve it at all. So when a domain flipped into challenge mode during an attack, its API endpoints went down with it — and because API clients don't store cookies, they looked like attackers to our flood detectors too.
API Zones fix this. Define path prefixes — /api/, /graphql, whatever your machine traffic uses — and requests matching a zone are treated as machine traffic end to end. They never get a challenge and never receive tag cookies, and they don't feed the browser-oriented flood detectors, so honest API clients stop being counted as attackers.
They're protected instead by per-client rate limiting — a token bucket keyed by a header you choose (Authorization is the usual pick, hashed so the raw credential is never stored), with an IP fallback — plus a zone-wide flood ceiling that arms a short attack window. Every response is API-correct: a rate-limited client gets a 429 with a Retry-After header, not an HTML redirect.
You choose what the attack window does: Signatures (block flagged attacker fingerprints), Strict key (also reject requests missing your key header), or Log only — detect and block nothing, so you can tune limits for a week before enforcing. Invalid zone config fails open to the normal web pipeline, so a bad zone never takes your site down.
Manage it all from a new API section on the domain page. The principle is simple: an API client can't prove it's human, so we don't ask — we verify it's identified and bounded instead. See What is a Layer 7 DDoS attack?