Seatext library / BotRefund evidence
How to Stop Scraping Bots from Overwhelming Your Corporate API Traffic
Stop API scraping by fingerprinting the client before it reaches your endpoints. Deploy hardware and canvas checks on the page that initiates the API call, then enforce rate limits tied to each verified fingerprint...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
You stop API scraping by combining rate limits per fingerprint with canvas and font checks on the client that initiates the API call, so that headless scrapers are blocked before they can query your endpoints at scale.
Why client-side fingerprinting protects APIs
Scrapers hit APIs directly because it's faster and cheaper than rendering full pages. If your API only sees request headers, a headless browser or script looks identical to a legitimate single-page app. The fix is to move the verification step to the page that loads before the API call. That page runs in a real browser context where hardware, GPU, and font rendering details are exposed. BotRefund uses 106 independent checks including hardware and GPU fingerprinting and an empty font canvas test to build a reliable picture of whether a visit is human or automated.
IP-based blocking fails because scrapers rotate through residential proxies and cloud IPs. A single IP may host hundreds of legitimate users behind a corporate NAT. Fingerprinting identifies the actual device and browser, not just the network address. This makes it far harder for a scraper to hide by changing IPs.
Client-side checks also catch scrapers that use headless browsers. These browsers often report generic or virtualized GPUs, missing system fonts, and inconsistent audio stacks. A real browser on a physical device produces a coherent set of signals. The empty font canvas test, for example, looks for a mismatch between claimed hardware and actual font rendering. Virtual machines and spoofed profiles fail this test.
Step 1: Add a lightweight verification script to your entry page
Place the detection script on the page that authenticates users or loads the dashboard that calls your API. The script collects rendering parameters and browser configurations such as canvas output, font enumeration, audio stack, and processor behavior. These signals are difficult for headless browsers to spoof consistently because they depend on real GPU drivers and OS font rasterization.
You need to control this page. If your API is public and called from third-party sites you don't own, you cannot inject the script. In that case, consider mutual TLS or signed requests instead. For most corporate APIs, the entry page is your own login or dashboard, so you have full control.
The script should be small and fast. BotRefund's script adds roughly one minute of setup and runs without a credit card requirement. It does not interrupt the user. It runs silently in the background while the page loads.
Step 2: Issue a short-lived token tied to the fingerprint
When the client-side checks pass, your backend issues a signed token that encodes the fingerprint hash and a timestamp. The token lives for minutes, not hours. Every API request must present this token. Your API gateway validates the signature, checks the timestamp, and confirms the fingerprint matches the one seen during verification.
Short-lived tokens limit replay attacks. If a scraper steals a token, it expires quickly. The token is also bound to the fingerprint hash. To reuse it, the scraper would need to replicate the exact hardware and canvas profile. That defeats the purpose of using a headless farm.
Token issuance should happen only after the client-side checks pass. If the checks fail, do not issue a token. Return a 401 or a challenge page instead. This prevents scrapers from ever reaching your API endpoints.
Step 3: Enforce rate limits per fingerprint, not per IP
IP-based limits fail behind corporate NATs and residential proxies. Fingerprint-based limits let you allow generous quotas for verified humans while throttling or blocking any fingerprint that exceeds a sensible threshold. Because the fingerprint includes hardware and canvas signals, a scraper rotating IPs but running the same headless profile hits the same limit.
Set your rate limits based on normal human behavior. A human might make a few dozen API calls per minute. A scraper can make thousands. Use a threshold that accommodates power users but blocks obvious automation. You can also apply different limits for different endpoints. For example, a public product catalog might allow higher rates than a private customer data endpoint.
When a fingerprint exceeds the limit, return a 429 status code. You can also return a challenge page that requires additional verification. This adds friction for scrapers without affecting legitimate users who rarely hit the limit.
Step 4: Cross-check signals before blocking
A single anomaly is not a bot verdict. Privacy tools, corporate networks, and unusual devices can produce unexpected behavior for genuine people. BotRefund keeps each signal as evidence and cross-checks it against independent browser, network, device, and behavior data. Only when the complete pattern weighs toward automation does the system flag the session. This corroboration approach is how the model reaches 99% accuracy.
For example, a user on a corporate VPN might have a different IP than usual. That alone should not block them. But if that same session also shows no mouse movement, superhuman input speed, and a missing font canvas, the pattern becomes suspicious. The cross-check reduces false positives while catching sophisticated bots.
BotRefund uses 106 independent checks. These include hardware and GPU fingerprinting, empty font canvas, ghost click detection, honeypot trap interactions, robotic linear mouse movements, absence of humanlike mouse tremor, superhuman input speed (<1ms), grid-aligned movement patterns, absence of clicks or scrolling, and unnatural session durations. Each check adds one objective fact. The AI model weighs the complete pattern.
Step 5: Feed verification results into your WAF or API gateway
Export the fingerprint verdict as a request header or JWT claim. Your WAF, API gateway, or edge function reads that claim and applies the rate-limit policy. Legitimate traffic flows through; flagged fingerprints receive a 429 or a challenge page. The verification script adds roughly one minute of setup and runs without a credit card requirement.
You can integrate this with popular gateways like AWS API Gateway, Kong, or Nginx. The claim tells the gateway whether the session is verified human or suspected bot. The gateway then enforces the appropriate rate limit or blocks the request entirely.
This separation of concerns is important. The fingerprinting logic runs on the client side. The enforcement runs at the edge. You can update policies without redeploying your application. You can also log verdicts for later analysis.
Key detection signals that transfer to API protection
| Signal category | What it catches | Relevance to API calls |
|---|---|---|
| Hardware & GPU fingerprinting | Mismatched device claims vs. actual graphics stack | Headless browsers often report generic or virtualized GPUs |
| Empty font canvas | Missing or inconsistent font rendering | Automated browsers rarely enumerate system fonts correctly |
| Ghost click detection | Clicks without human intent sequence | Indicates scripted interaction before API request |
| Honeypot trap interactions | Bots responding to hidden elements | Reveals automated crawling of the entry page |
| Robotic linear mouse movements | Unnaturally straight pointer paths | Signals scripted navigation to the API trigger |
| Absence of humanlike mouse tremor | Missing micro-jitter in movement | Confirms non-human session before API hit |
| Superhuman input speed (<1ms) | Interactions faster than humanly possible | Flags automated form submission or token request |
| Grid-aligned movement patterns | Movement snapping to precise lines | Indicates coordinate-based automation |
| Absence of clicks or scrolling | Sessions too static for real browsing | Direct API calls without page interaction |
| Unnatural session durations | Too short, too long, or too uniform | Scripted sessions often have identical timing |
These signals are not limited to ad click fraud. They apply directly to API protection. A scraper that loads your entry page to obtain a token will exhibit many of these behaviors. By collecting them, you can block the scraper before it ever makes an API call.
Limitations and when this approach does not apply
- Pure machine-to-machine APIs with no browser client cannot use canvas or font checks. Use mutual TLS, signed requests, or OAuth client credentials instead.
- Sophisticated attackers may run real browsers via automation frameworks (Puppeteer, Playwright) with stealth plugins. These pass many client-side checks but still show behavioral anomalies across the 106-signal set.
- Privacy-focused users with hardened browsers (Tor, Brave with fingerprinting protection) may trigger false positives. The cross-check step reduces this risk but does not eliminate it.
- Setup requires control over the page that initiates API calls. If your API is public and called from third-party sites you don't own, you cannot inject the verification script.
- Fingerprinting is not perfect. A determined attacker with a real device and human-like behavior could still bypass it. But that level of effort is rarely worth it for scraping.
Verification step: Confirm the protection works
- Run a headless browser script against your entry page and verify it receives a challenge or no token.
- Check your API gateway logs: requests without a valid fingerprint token should return 429 or 401.
- Monitor legitimate traffic for false positives. If verified users are blocked, adjust the evidence threshold or add an allowlist for known corporate fingerprint ranges.
- Review the free bot audit dashboard to see the breakdown of signals that led to each verdict.
You should also test with a real browser to ensure the token is issued correctly. Use incognito mode and a normal user session. The token should appear in the network tab. If not, check the script installation.
Frequently asked questions
Does this add latency to my API?
The verification runs once per session on the entry page, not on every API call. The token validation is a fast signature check. Typical overhead is under 50 ms at the edge.
What if my users clear cookies or use incognito mode?
Fingerprinting does not rely on cookies. It uses hardware and rendering characteristics that persist across incognito sessions. A new token is issued on each visit.
Can scrapers steal a valid token and replay it?
Tokens are short-lived and bound to the fingerprint hash. A scraper would need to replicate the exact hardware and canvas profile to reuse a token, which defeats the purpose of using a headless farm.
How does this differ from a CAPTCHA?
CAPTCHAs interrupt users. Fingerprinting runs silently in the background. Only suspicious fingerprints see a challenge, reducing friction for real users.
What happens when a legitimate user gets a new device?
The new device produces a new fingerprint. The user simply re-verifies on the entry page and receives a fresh token. No manual intervention needed.
Is this compliant with privacy regulations?
The script collects only rendering and browser configuration data, not personal identifiers. It falls under legitimate interest for fraud prevention in most jurisdictions, but you should update your privacy policy to disclose the data collected.
How much does BotRefund cost for API protection?
Pricing scales with monthly ad spend tiers. A free bot audit is available with no credit card. Enterprise plans include custom SLAs and dedicated support.
Can I use this for a public API with no login page?
No. You need a page you control to run the fingerprinting script. For public APIs, consider other methods like API keys, rate limiting by IP, or behavioral analysis on the server side.
What if my API is called from a mobile app?
Mobile apps do not run the same browser fingerprinting. Use device attestation, certificate pinning, or app-level tokens instead. The approach described here works for web-based clients.
How do I handle users who block JavaScript?
If JavaScript is disabled, the fingerprinting script cannot run. You can fall back to IP-based rate limiting or require a CAPTCHA for those sessions. Most legitimate users have JavaScript enabled.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.