Hyper Solutions founder Patrick van den Bosch on browserless bypasses, session consistency, AI-assisted reverse engineering and the economics of solving at scale.
Akamai, DataDome, Incapsula and Kasada each ship JavaScript that inspects the visiting client, encodes what it finds and sends it back to be judged. Much of that code is heavily obfuscated, and some of it runs inside a custom virtual machine designed to keep it unreadable.
Reverse engineering one of these systems means working out what the script collects, how it encodes it, and which values the server actually checks. Then the vendor ships a new build, and on some systems that happens daily.
Patrick van den Bosch and his team have been working through that cycle since 2020. He is the founder of Hyper Solutions, which builds request-based solutions for all four vendors. During our recent Reddit AMA, he described where his team's time really goes:
Most of the time is usually spent testing, understanding how the antibot updates and how to maintain it at scale.
The Hyper Solutions team started out as sneaker developers. According to the company, its API now handles more than 2.5 billion requests a month.
In our thirteenth r/WebScrapingInsider AMA, we asked Patrick how he approaches an unfamiliar protection, why bypasses that work in testing fail later, where AI helps, and how to judge whether a bypass is worth the cost.
Here are the nine biggest lessons from the discussion.
1. A Browserless Bypass Reproduces What the Browser Would Have Sent
If an anti-bot checks whether you're running a real browser, how do you pass without one?
Conceptually: generating the outputs the anti-bot expects. We don't sandbox or use browsers while generating the payloads.
When a protected page loads, the protection's JavaScript collects information about the device and environment, encodes it and sends it back. That encoded blob is the sensor payload. It's one of the inputs the vendor uses to decide whether to issue or keep a valid session, though the exact sequence varies by vendor and challenge.
A headless browser runs the vendor's script and produces the right data as a side effect. A request-based setup skips running it and produces the data the script would have produced, for a specific, consistent device profile.
Because scripts change constantly (Patrick noted that DataDome ships daily builds), the generator has to work from the exact script the page served in that session. Some parts, like proof-of-work challenges, are simply computed.
Browsers don't disappear from the work. Patrick described a clean Chrome capture as the ground truth for header order, TLS and request sequence, and said browsers remain the right tool for long-lived logged-in sessions and very state-heavy flows.
2. A Working Scraper Might Only Be Getting Tolerated
Asked which common belief leads developers most astray, Patrick pointed to the assumption that a successful response means you've been accepted:
A successful response indicates that the site did not block the request. It doesn't tell you that the anti-bot system thinks you're a browser.
He gave four reasons a short successful test can mislead:
- Passive enforcement. A protection can score traffic without blocking it. Akamai's SBSD, for example, has passive and enforced modes.
- Endpoint differences. A weak session can browse product pages and still get blocked on search, basket or login.
- Delayed rejection. Some sites invalidate Akamai's
_abckcookie after a set number of requests or certain actions. - Different thresholds. Two sites using the same vendor can enforce very different rules.
Automated traffic, he said, can be recognised and still allowed through until the site tightens a setting, at which point a "working" setup fails overnight.
The most useful debugging detail came from his description of DataDome. The request that gets blocked isn't necessarily the one that's wrong:
DataDome is really good at detecting small inconsistencies in your request flow and headers. These are hard to debug, and will only get you a 403 error on the actual protected endpoint. The mistake could be in any of the five to 10+ requests that happened before the protected request.
To illustrate: a scraper fetches product pages fine but fails every time it searches. The search request looks perfect. The real problem is an unexpected request or header-order mistake three steps earlier. Search is just where the rejection becomes visible.
That's why Patrick's support team asks for a HAR file recording the full request flow, not just the failing request.
3. Consistency Beats Random Fingerprint Tweaks
Many hidden failures come from contradictions between pieces of client information that each look fine on their own: the TLS fingerprint (the ciphers and extensions offered during the handshake), header values and order, the User-Agent and client hints, cookies, IP and the sensor payload.
That's the core of how these systems work: they judge the whole session, not one request. The TLS fingerprint, header order, client hints, IP, cookies and the sensor payload all have to describe the same browser. One small contradiction (a UA that says Chrome 155 with
sec-ch-uafrom 154, or high-entropy client hints the site never asked for) is often enough.
The instinctive fix for detection is to vary things. Patrick warned that random values no real device would produce together are worse than one consistent profile.
The same risk applies to shared infrastructure. Asked whether a widely used solver could develop its own detectable fingerprint, he said yes:
If a solver emits outputs from a small, fixed set of device profiles, or has any field that's constant where real browsers vary, then all its customers form a cluster, and a vendor only has to find that cluster once. The defence is making the output population look like the real browser population: lots of real device profiles, consistency within each one, and not inventing values. Randomness isn't the fix, randomness is a fingerprint on its own.
Patrick noted that Akamai in particular can take a while to cluster traffic before blocking it. So a hundred successful requests provides limited evidence of how an implementation behaves at scale.
4. Experts Build for the Next Update, Not the Last Capture
Patrick's investigation process is designed to produce something maintainable, not to reproduce one successful capture.
Understand the flow before the script
Observe before reading code. Record a clean browser session and map which requests set which cookies/tokens, and which requests depend on them. You want the dependency chain before you open a single script.
From there, his team works out which collected information is actually enforced by stripping things away and seeing what breaks. Only then do they analyse the code. They usually write decrypters for the browser's own payloads first, which gives them a reference output to compare their generator against. Finally they diff their output against the browser and test at volume, because some checks only show up statistically.
You don't need to understand the whole script to get something working, Patrick said. But to make it reliable, you need to know where every value comes from, because the server can start checking any of them without warning.
Separate routine variation from structural change
According to Patrick, anti-bots now update far more often than a year ago, and every vendor he supports ships either a dynamic script per request or a rotating pool. That doesn't mean every build needs a new investigation:
When it comes to daily builds, a vendor like DataDome does this, but they only rotate dynamic values. Once you make a parser for that, a daily update requires no manual intervention anymore.
Structural changes are different. A bytecode virtual machine compiles a protection's logic into custom instructions that run on its own interpreter, hiding what the code does. When Incapsula introduced one, Patrick said, it took his team five days to get their API running again. Most updates, he added, take around an hour with the right tooling. Those are timings from a team with years of tooling, not what someone starting from scratch should expect.
Separate vendor research from site integration
Core vendor research can carry across sites. Patrick said the same sensor format, cookie mechanics and challenge types apply to every Akamai site. But versions, challenges and configurations still matter. Each site decides which challenges it enforces, how sessions renew, which requests are protected, and whether it adds its own tokens. Etihad, in his example, ran Akamai on the website and Incapsula's reese84 on the API.
5. AI Speeds Up Integration More Than It Cracks Obfuscation
Asked about REA, a popular tool that connects AI agents to reverse-engineering tools, Patrick was enthusiastic about one part of the job:
Understanding the flow: very good. Mapping which request sets which cookie, which script is loaded where, what the dependency chain looks like from a HAR. Agents are genuinely great at this already.
He said agents also help with integration code, supporting tools and patching updates, as long as the code is already deobfuscated. The wall is understanding what heavily obfuscated code actually computes:
A generic JS analyser recovers structure, not semantics: you get "there's a giant interpreter loop here", not "this opcode reads
navigator.webdriverand mixes it into the payload".
Feedback is the other problem. An agent can build something that looks right and get a 403 with no explanation.
Patrick also described a demo his company published: Claude Code built a full request-based scraper for Etihad (Incapsula's reese84 with proof-of-work and a seven-request flow) from a single prompt in about 16 minutes. It's a company-reported measure of integration speed, and the agent had Hyper's solver API, a Claude Code plugin and an MCP connection to powhttp to work with. It wired up existing infrastructure. It didn't reverse engineer the anti-bot.
6. A Stable Success Rate Can Hide Rising Costs
Faster implementation only matters commercially if collection stays reliable and affordable.
A solve produces a cookie that carries many requests until it's invalidated. Patrick said that depending on the site, Akamai can invalidate after protected actions or a set number of requests, while reese84 needs renewing roughly every 15 minutes. One solve can cover tens or hundreds of pages.
That makes sessions an economic variable. If sessions shorten or retries climb, your success rate can hold steady while solves and bandwidth costs rise.
The single most useful number is solves per 1,000 successful pages / actions. It folds session lifetime, requests per cookie and retries into one figure, and it's the one your margin actually depends on. Next to it, bytes per 1,000 successful pages for the proxy side. If either jumps, something changed, even if your success rate still looks fine.
Bandwidth matters because residential proxies are billed per GB. Patrick cited a joint study with SOAX on Hyatt hotel searches behind Kasada. A default headless browser used about 4.0 MB per search, compared with about 178 KB for a request-based client, roughly 22 times less. That's one workload. With images, fonts and third-party scripts blocked, the browser used about 1.1 MB per search.
Which approach fits depends on your situation:
| Approach | Circumstances Patrick associates with it |
|---|---|
| End-to-end unblocker | Lower volume, many targets and limited integration time |
| Managed browser | Complex interactions and long-lived account state |
| Solver with a request-based scraper | Repeated collection from specific targets at scale |
| In-house reverse engineering | Teams prepared to own research and ongoing maintenance |
I'd recommend a browser or an end-to-end API over our approach when the volume is too low to justify building a scraper, or when the flow depends on long-lived account state.
7. The Hardest Protection to Understand May Not Be the Hardest to Operate Against
Asked which vendor is hardest, Patrick broke difficulty into separate criteria. Obfuscation determines how hard the code is to read. Signals describes how well the server checks what's collected. Dynamicness covers how much the scripts vary. A vendor that gets all three right, he said, is the hardest to bypass.
A protection can be hard on one dimension and easy on another:
Kasada has good obfuscation with their VM, but their signals are poor and easy to scale.
Flow detection, tracking the sequence of requests you send to the site, is another dimension again. Patrick named DataDome as the vendor that gives him the most trouble because it is strong at this. A small mistake, such as the wrong header order, can lead to a block several requests later.
Difficulty has several dimensions, so a vendor ranking alone says little about integration effort, maintenance or performance at scale.
8. Some Access Problems Sit Outside the Payload
Asked whether every client-side protection can be bypassed in principle, Patrick said that anything running purely client-side can be, because the client controls every input the check sees.
But many access decisions don't rest only on what the client computes. IP reputation, how an account behaves over weeks and patterns across sessions are judged on the server:
You can't compute your way out of a burned IP or an account with a bad history.
On mobile, hardware-backed attestation such as Play Integrity and App Attest has the device vouch for itself with keys you don't control. And for stateful, long-lived sessions, a real browser is sometimes simply the more sensible tool.
The practical limit matters more often than the theoretical one. Patrick said "we can't bypass this" usually means "we can't do it reliably at an acceptable cost." If something takes a week to get working and breaks every few days, the answer is effectively no.
Reproducing what the client sends doesn't control every input to an access decision, and a technically possible approach can still be uneconomical to maintain.
9. Hard-to-Access Data Is Becoming a Weaker Business Moat
A founder planning a data product asked whether data sitting behind one of these four vendors is a real moat.
The difficulty of access is a weak moat, and it's becoming weaker.
Patrick argues that existing solver infrastructure and AI-assisted integration substantially lower the barrier to accessing protected data. If access is getting cheaper for you, it's getting cheaper for competitors too.
What stays defensible, in his view, are three things:
- Reliability over time. Getting data once is easy. Getting it every hour for a year, through script updates, Chrome releases and proxy changes, is the real challenge.
- Coverage and history. A competitor starting today can't collect the last two years.
- What you do with the data. Cleaning, matching and normalising sources, and building a product people want to use.
For a data business, the question is what still sets you apart once competitors can get the same access.
Conclusion: Access Is a Moment, Continuity Is the Product
A 200, a solved challenge or a 16-minute build shows that you had access at one moment.
Valuable data products depend on collection that keeps working through script updates and site changes, coverage that builds up over time, and outputs people actually use.
As Patrick summarized:
It's a maintenance problem, not a puzzle. The interesting engineering is in staying working, not in getting working.
To see Patrick's answers in context, read the full AMA thread on r/WebScrapingInsider.