Itnetic TechnologiesFor APIs
A Cloudflare alternative for APIs that never challenges a machine
An SDK cannot solve a browser challenge, and a webhook cannot read an HTML interstitial. Itnetic protects API paths with per-client rate limits, behavioral signatures and TLS fingerprinting instead — and always answers with a status code your client understands. Every plan, including free.
Most edge protection was designed around a browser. The core defence is an interstitial that runs some JavaScript and hands back a signed cookie — instant for a real visitor, impossible for curl, an SDK, a mobile app or an inbound webhook. The failure mode is nasty and quiet: the moment your domain goes into challenge mode during an attack, your integrations start receiving HTML where they expected JSON, and your own clients start looking like the attack because they hold no cookies.
Itnetic solves that with API Zones. You declare the path prefixes your machine traffic uses — /api/, /graphql, /v1/ — and requests matching a zone are treated as machine traffic end to end. They are never challenged, never given tag cookies, and never counted by the browser-oriented flood detectors. They are protected by different machinery instead.
The table below compares capability only, from each vendor’s public documentation, and makes no claim about anyone else’s pricing or performance.
API protection
Protecting an API: what each side gives you
Availability by plan. Capabilities only — no pricing or performance claims.
| API requirement | Itnetic | Cloudflare |
|---|---|---|
| Path prefixes marked as machine traffic (never challenged) | Every plan — API Zones | Plan-dependent configuration |
| Rate limiting keyed on a header you choose (e.g. Authorization) | Every plan — hashed, raw credential never stored | Plan-dependent |
| Zone-wide flood ceiling separate from the per-client limit | Every plan | Plan-dependent |
| Rate-limited response | 429 with Retry-After | 429 (configurable responses plan-dependent) |
| Log-only mode for tuning limits before enforcing | Every plan | Plan-dependent |
| Reject requests missing your key header (strict mode) | Every plan | Plan-dependent (API Shield) |
| JA4 TLS client fingerprinting | Every plan — logged on every request | Plan-dependent (JA3/JA4 fields) |
| Cross-tenant fingerprint reputation | Every plan — challenge-only, opt-in per domain | Plan-dependent |
| mTLS client certificates | Not offered | API Shield |
| OpenAPI schema validation at the edge | Not offered | API Shield |
| Per-request logs with the WAF verdict and rate-limit outcome | Every plan | Raw log export on Enterprise (Logpush) |
| Managed OWASP filters in front of API paths | Every plan, including free | Paid plans |
| Origin load balancing with passive failover | Every plan — up to 8 origins | Paid add-on |
| Public REST API to manage it all | Every plan | Every plan |
| Bad config behaviour | Invalid zone fails open to the normal pipeline | Not documented per-feature |
About this comparison
Compiled from Cloudflare’s own public documentation and plan pages on 10 September 2026, and describing feature availability by plan at that date. Plan contents change — check Cloudflare’s current pages before making a decision. Cloudflare is a trademark of Cloudflare, Inc.; Itnetic Technologies is not affiliated with, endorsed by or sponsored by Cloudflare, Inc. Prices named on this page are Itnetic’s own; this page makes no claim about any other provider’s pricing, performance, capacity or availability.
Why a browser challenge is the wrong tool for an API
A challenge asks a client to prove it is a browser. An API client cannot pass that test and should not have to. Worse, the failure is invisible until it is expensive: your mobile app gets a 503 carrying an HTML body, your payment webhook retries into the same wall, and your monitoring reports "the API is up" because the edge answered. API Zones remove the test entirely for declared paths and replace it with identity and bounds — is this client identified, and is it inside its budget?
- Zoned requests never receive a challenge or a tag cookie.
- They never feed the navigation-based flood counters, so honest clients stop being mistaken for the attack.
- Every answer is API-correct: 429 with Retry-After, or 403 — never an interstitial.
Per-client limits that key on the client, not the IP
Rate limiting by IP address is close to useless for an API: half your traffic is behind a mobile carrier NAT and the other half is one server calling you a thousand times a minute, legitimately. Itnetic keys the token bucket on a header you nominate — Authorization is the usual pick — hashed at the edge so the raw credential is never stored, with an IP fallback for anonymous endpoints. On top of that sits a zone-wide ceiling that arms a short attack window when the whole endpoint, not one client, comes under load.
Three attack modes, including one that blocks nothing
Tuning a rate limit against production traffic is the part everyone gets wrong. There are three zone modes: Signatures blocks flagged attacker fingerprints during an attack window; Strict key additionally rejects requests missing your key header; and Log only detects and blocks nothing at all, so you can run a week of real traffic through the limits and read what would have happened before anything enforces. An invalid zone configuration fails open to the normal web pipeline, so a typo cannot take your API down.
Fingerprinting instead of puzzles
Since a machine client cannot be challenged, the interesting signal is what its connection looks like. Itnetic computes a JA4 TLS fingerprint once per connection from the ClientHello and logs it on every request, alongside a 20-feature request vector. A fleet-wide reputation feed scores fingerprints that show up as automated across many different customer sites — and because a fingerprint identifies a client population rather than a person, being wrong must be cheap: reputation is challenge-only on navigations, never a block, never a kernel drop.
Logs that tell you which rule did it
Every request is logged with the path, method, status, origin latency, TLS version, client fingerprint and the exact verdict — which WAF rule matched, whether the rate limiter fired, whether the request was zoned. That is on every plan including free, and it is the difference between debugging an integration failure in ten minutes and guessing at it for a day.
FAQ
Cloudflare alternatives: common questions
How do you DDoS-protect an API without breaking clients?
You stop asking machine traffic to prove it is a browser. Declare your API path prefixes as zones, protect them with per-client rate limits keyed on an identifying header, add a zone-wide flood ceiling, and make every rejection an API-correct status code — 429 with Retry-After, or 403. That is what Itnetic API Zones do, on every plan.
Will my API get an HTML challenge page during an attack?
Not on a zoned path. Requests matching an API Zone are never challenged and never given tag cookies, even while the rest of the domain is in challenge mode.
Can I rate limit per API key instead of per IP?
Yes. The token bucket keys on a header you choose — usually Authorization — hashed at the edge so the raw credential is never stored, with an IP fallback for endpoints that have no key.
Does Itnetic support mTLS or OpenAPI schema validation?
No. Those are genuine gaps against a dedicated API security product, and if mutual TLS or edge schema enforcement is a hard requirement, Cloudflare API Shield or an equivalent is the right tool. Itnetic covers availability, abuse and visibility for APIs, not contract enforcement.
Does it work for GraphQL and webhooks?
Yes — a zone is a path prefix, so /graphql or /webhooks/stripe behaves the same as /api/. Webhooks are the case that benefits most, because an inbound webhook has no retry budget for an interstitial it cannot parse.
Can I test limits before enforcing them?
Yes. Set the zone to Log only. Detection runs and nothing is blocked, so you can read a week of real traffic against the limits you are considering before turning enforcement on.
Is API protection included on the free plan?
Yes. API Zones, rate limiting, fingerprinting, managed WAF and per-request logs are all on the free Starter plan. Plans differ only by domain count and delivered bandwidth.
More Cloudflare comparisons
Same provider, different question — each page compares what matters to one specific use case.
Other comparisons
Same method, different provider — feature availability by plan, with the date it was checked.
Try it on one domain.
Two DNS records, no nameserver change, free plan with no card.