APIs are built for automation. That makes “block the bots” a fairly useless brief.
The same inventory endpoint might serve a mobile app, a partner feed and a scraper. All three clients can send valid requests. All three can hold valid credentials. The real question is whether that client is using that route in a way the business intended.
That sounds obvious. In practice, many API controls are still applied across a hostname or an IP range, with little regard for what the route actually does.
Begin with the route that can hurt you
Pick a sensitive operation: login, password reset, account lookup, checkout, reservation, coupon redemption or a costly GraphQL query. Ask its owner three things:
- Who is meant to call it?
- What does normal use look like?
- What should happen when use falls outside that pattern?
The answer will not always be “block”. A public catalogue may tolerate a fair amount of crawling. A reservation endpoint probably should not let one client hold the entire available inventory. A partner export needs a machine-readable error and a phone call to the partner, not a browser challenge.
OWASP describes this problem as API6:2023 Unrestricted Access to Sensitive Business Flows. It includes automated purchasing, reservation abuse and referral fraud: ordinary application functions used for an unwanted purpose. The OWASP Automated Threats project covers the familiar variants, including credential stuffing, scraping, scalping and inventory denial.
Security can help enforce the decision, but it cannot invent the decision. The product or service owner has to say which use is legitimate and what the business is prepared to do about the rest.
Find the API you actually have
Policies written against an architecture diagram miss old mobile versions, forgotten staging hosts and endpoints that never made it into the OpenAPI file. Those routes still reach real systems.
API9:2023 Improper Inventory Management calls for an inventory of hosts, environments, versions, endpoints and data flows. This is not paperwork for its own sake. You need a real route and method before you can attach a useful control to it.
Peakhour API Security discovers REST, GraphQL and WebSocket routes, including shadow and legacy endpoints. Where an OpenAPI or Swagger contract exists, Peakhour can show requests that have drifted from it.
Schema is useful, but it is not intent. A perfectly valid checkout can still be abusive. Schema tells us what arrived and where; the route policy tells us whether to allow it.
Do not make JavaScript a requirement
A partner integration or machine-to-machine service does not need JavaScript to be protected. Peakhour can assess direct API traffic using route, method, schema result, authentication outcome, headers, protocol behaviour, network path, response code and request cadence.
JavaScript is useful when the API call belongs to a browser-backed journey. It can add browser and device consistency signals, or support a challenge before a sensitive account action. That is optional evidence. A direct API client does not need JavaScript, and its absence is not evidence of abuse.
This has an operational consequence: choose an action the intended client can complete. A customer resetting a password in a browser may be able to pass a step-up check. A partner batch cannot.
Count something that survives an IP change
An IP limit is easy to understand and sometimes it is enough. It is a poor fit for distributed credential testing, residential proxy traffic and clients behind carrier-grade NAT.
API4:2023 Unrestricted Resource Consumption recommends limits suited to the operation. Password recovery, one-time-code validation, GraphQL batching and large responses have different costs and should not share one threshold.
Peakhour's Advanced Rate Limiting can count using documented inputs including path, headers, IP, ASN, country, TLS fingerprint, response code and bot-verified status. Each rule has a threshold, interval and action, with counters showing what it allowed, blocked or saw cross the threshold.
The important part is being able to explain the counter. “One hundred requests per minute” is not much of a policy until we know the route, which clients are grouped together, and why one hundred is the point at which use becomes harmful.
Application context can improve that policy. An account, tenant, session or API credential may be a better unit than a network address, provided the integration supplies it safely. Do not casually copy credentials into logs or rule labels.
Treat fingerprints and proxy detection as evidence
Attackers rotate addresses because IP-only controls are easy to distribute around. Legitimate traffic also shares addresses in offices, hotels, universities and mobile carrier networks.
TLS behaviour, HTTP/2 settings, header shape and browser consistency can group requests into a client cohort even as the source IP changes. That can reveal a tool family or a recurring campaign. It does not reveal the person operating it. Fingerprints collide, change and can be copied. They are evidence, not identity.
The same caution applies to residential proxy detection. A proxy signal can justify closer inspection or a tighter limit on a sensitive route. It is not a sound reason to block every request that looks residential.
Expect the first policy to be wrong
A mobile release changes its request shape. A partner runs a larger batch. A sale changes normal checkout traffic. The attacker slows down and moves from login to token refresh.
We start sensitive API controls in monitoring unless the active harm demands an immediate block. Keep the route, evidence, action and response outcome together. Log forwarding sends that record to the customer's existing SIEM or observability platform.
Before tightening a policy, we want two answers:
- What unwanted activity did it reduce?
- Which intended clients did it inconvenience?
The Gumtree case study is not an API-only case study. It is relevant because it records how this tuning works in production. Gumtree and Peakhour deployed progressively and adjusted controls against live traffic. Gumtree reported a 3.3x cleaner origin mix and an 80% reduction in Gumtree's internal fraud score. Those figures belong to the broader bot-management deployment, not to an isolated API feature.
One request should produce one decision
An automated campaign does not respect product categories. The same traffic can use valid API calls, stolen credentials, residential proxies and changing client fingerprints while also carrying payloads that need WAF inspection.
Peakhour puts API protection, managed WAF/WAAP, bot management, advanced rate limiting, DDoS protection, anomaly detection and origin protection in the same request path. It can run on Peakhour Edge or alongside an existing CDN or edge provider. Operators get one decision to review, with the evidence that produced it, rather than a pile of unrelated scores.
API Bot Protection shows how we apply that model to login, token, checkout and account routes.
