Between "run a headless browser" and "give up" there is a category most people meet by accident, usually while reading somebody else's code. A solver API does one narrow thing: it produces the payload an anti-bot vendor's JavaScript would have produced, and hands it back over plain HTTP, so your HTTP client can post it and carry on. No browser starts. No page renders. The challenge is answered by arithmetic rather than by simulation.
That narrowness is what makes it worth understanding properly, because it is regularly confused with three other things it is not.
What it actually does
The shape is the same at every vendor that sells one. You fetch the protected page with your own client, through your own proxy. The response carries a challenge: a script reference, a cookie in an untrusted state, sometimes a block page. You send that context to the solver API. It returns a payload. You post the payload to the target, again on your own connection, and the target's own server issues the trust cookie that lets you through.
Your client
through your proxy
Target
returns a challenge
Solver API
returns a payload
Target
you post the payload
Trusted session
target sets the cookie
The detail that matters most is in the last node. The solver does not contact the target on your behalf and does not set any cookie. It computes a value and gives it to you. Hyper Solutions states the boundary plainly on their Akamai page:
You stay in control of every request to the target: your proxies, your session, your cookie jar. We do one thing, turn the sensor challenge into a valid payload.
That sentence is the whole category in one line, and it is worth reading twice if you are trying to work out whether a solver replaces anything you already run. It does not. Everything about how your traffic reaches the site remains yours to get right.
The three things it is not
Category confusion here is expensive, because the four options below fail in different ways and cost different amounts.
Four things people call 'the anti-bot solution'
| Approach | What you send | What you get back | Who holds the connection |
|---|---|---|---|
| Solver API | Challenge context from the page | A payload, token or header | You |
| CAPTCHA solver | A puzzle image or sitekey | A solution token | You |
| Scraping API | A target URL | The page or structured data | The vendor |
| Headless browser | Nothing, you run it | A rendered page | You |
Not a CAPTCHA solver. A CAPTCHA is a puzzle a human is supposed to see. reCAPTCHA and hCaptcha are the visible tier, and solving one gets you a token for that specific widget. The layer a solver API answers is invisible and runs on every request whether or not a challenge is ever shown. Most anti-bot blocks never display anything to solve, which is exactly why so many people arrive at a CAPTCHA service, buy credits, and discover their problem is untouched. The two occasionally meet: Incapsula can escalate to hCaptcha or GeeTest, at which point you need both, one for the sensor and one for the puzzle.
Not a scraping API. This is the sharpest distinction and the one with the biggest consequences. A scraping API takes a URL and returns data, which means the vendor makes the request. Their proxies, their session, their fingerprint, their rate limits, and their bill for the bandwidth. A solver API returns a payload and nothing else, so every byte to the target still leaves from your infrastructure. If you already run proxies and a scraper you like, a solver slots into it. A scraping API replaces it. We priced what that vendor-side model costs in scraping API credit multipliers, and the short version is that residential access there is a per-request multiplier rather than a rate.
Not a headless browser. Puppeteer and Playwright defeat detection by actually being a browser, which works and is expensive in a way that is easy to miss. The browser fetches the whole page: images, fonts, tags, everything the document references. Through a residential proxy billed per gigabyte, that page weight is a direct cost. We did that arithmetic in what Puppeteer costs in proxy bandwidth, and the gap on a measured flow is about 19 times the bandwidth for the same data.
What the four major systems demand
Solvers are built per vendor, because each anti-bot system asks for something structurally different. Coverage is a list, not a capability, and a system outside a vendor's list is not partially handled.
What each anti-bot system wants, and what a solver returns for it
| System | The tell | What has to be produced |
|---|---|---|
| Akamai Bot Manager | _abck and ak_bmsc cookies | Sensor data, posted about three times, plus SBSD tokens and SEC-CPT answers when they fire |
| DataDome | 403 interstitial, slider puzzle | An interstitial fingerprint payload, a slider solution, or trust tags |
| Incapsula / Imperva | reese84 and ___utmvc cookies | A signed reese84 sensor payload and a ___utmvc cookie value |
| Kasada | 429 carrying ips.js | A /tl payload, an x-kpsdk-ct token, and a fresh x-kpsdk-cd proof of work per request |
Challenge taxonomy per Hyper Solutions' published product documentation
Reading down the third column is the fastest way to understand why one generic bypass does not exist. Akamai wants a repeated conversation before it trusts you. Kasada wants a proof-of-work value recomputed on every protected request. DataDome sometimes wants a puzzle piece dragged to the right position. These are not variations on a theme, they are separate engineering problems, which is why solver vendors publish per-system coverage and price per system.
What it costs
Pricing in this category is per solve, which makes it unusually easy to compare against the alternative. Hyper Solutions publishes theirs openly rather than behind a sales call, so it works as a reference point for the shape of the market.
Published per-solve pricing
| Plan | Rate | Notes |
|---|---|---|
| Pay as you go | 3 EUR / 1,000 | Flat across every vendor, self-serve, top up a balance |
| Subscription | from about 1.40 EUR / 1,000 | Monthly per-vendor commitment, 350 EUR for 250,000 Akamai solves |
| Akamai entry | from 1.00 EUR / 1,000 | Lowest per-vendor entry of the four |
| Kasada entry | from 1.25 EUR / 1,000 | Includes Vercel BotID |
| Incapsula entry | from 1.50 EUR / 1,000 | reese84 and ___utmvc |
| DataDome entry | from 2.00 EUR / 1,000 | Interstitial, slider and tags |
hypersolutions.co, published pricing read 6 August 2026
Two structural details are worth knowing before you model this against a browser farm. Proof-of-work solving on Akamai's SEC-CPT crypto variant runs locally inside their SDK and costs no API call at all, so the puzzle that looks most expensive is the one you do not pay for. And every account starts with a free week, which means the only benchmark that matters, your target, is measurable before you commit anything.
The comparison people usually get wrong is treating the per-solve fee as a new cost against a free alternative. It is not free on the other side either. A headless browser pays in proxy bandwidth, RAM and maintenance, which is the arithmetic we ran in what Puppeteer costs in proxy bandwidth.
How to tell a serious solver from a bad one
This is a young market with real cowboys in it, so a few signals separate the vendors worth integrating from the ones that will strand you.
Do they say no? The most useful thing a solver vendor can tell you is that they cannot help. Hyper Solutions puts it as "if we cannot solve your target reliably, we will tell you before you spend a dollar", and invites people to ask before they build rather than after. A vendor who claims universal coverage is describing a product that does not exist, because each solver is reverse-engineered per system.
What happens when the vendor patches? This is the entire reason to buy instead of build, and it is worth quoting directly:
The whole point of buying instead of building: vendor patches, fingerprint rotations, and new challenge variants stop being your 2am incident.
Anti-bot systems move constantly. Akamai rotates a script, Kasada changes the proof of work, DataDome adds a fingerprint field. A solver that is not actively maintained is worse than no solver, because it fails silently at the worst moment. Ask how success rates are monitored and how fast patches ship.
Who answers when it breaks? Support quality in this space correlates strongly with whether the people answering built the thing. Hyper Solutions routes support through Discord to the same engineers who reverse the anti-bots, and describes their own team as "not ex-FAANG" but "ex-sneaker developers who have been beating these exact antibots since 2020". That background is the relevant credential here, and it is a fair proxy for whether a vendor will still be current in six months.
Do they care who you are? The reputable end of this market verifies customers, and you want to be buying from that end. Hyper Solutions verifies each use case on a domain-by-domain basis and scopes acceptable use to "public web data only. No auth bypass, no personal data harvesting." A vendor with no acceptable-use policy is a vendor whose other customers are your reputational risk, and increasingly your legal one.
Where your proxy fits, and why it got stricter
A solver API does not carry traffic, so proxies do not become optional. They become load-bearing in a way they were not before.
Every one of the four integrations above takes your egress IP as a required input. Hyper Solutions documents the ip field as the address the payload is generated for, and states it must match the IP your request to the target exits from. Their SDK examples call the variable proxy_ip, which is about as clear a statement of intent as documentation gets.
Your proxy is an argument to the solver
The payload is computed for one specific exit address. Generate it for one IP, send it from another, and you have handed the target a signed statement about a client that is not the one talking to it. That is a cleaner contradiction than sending nothing at all.
Three practical consequences follow, and they run against habits people build while fighting rate limiters.
- Sticky beats rotating. A trusted session is a matched set of cookie, fingerprint and address. Rotating the exit mid-session breaks the set and you re-run the whole handshake. Rotate between sessions instead, as covered in sticky versus rotating sessions.
- Datacenter still loses first. DataDome's own documentation says datacenter and proxy ranges are penalised on sight, regardless of how clean the payload is. A solver cannot argue with a reputation verdict reached before any script ran. That gate is what residential IPs are for.
- Geography still has to agree. A German exit with a US-English accept-language is a contradiction the payload faithfully reproduces, because you told it to.
What it does not fix
Worth being blunt, since the marketing around this category is not.
A solver API answers the challenge layer. It does not make your TLS handshake look like Chrome, it does not repair header ordering that betrays your HTTP library, it does not slow your request pacing to something human, and it does not clear a reputation block on your IP range. Those remain yours. The realistic mental model is that anti-bot defence is scored from several inputs at once, a solver owns one of them, a proxy owns another, and your client owns the rest.
It also does not extend past its published coverage. If your target runs Cloudflare, PerimeterX, F5 Shape or Radware, a solver built for Akamai has nothing to offer, and the honest vendors say so before you integrate rather than after.
When it is the right shape
The case is narrow and, inside that range, strong. Reach for a solver API when the target runs a system the vendor actually covers, when you are reading many pages rather than a handful, and when you want to keep owning your own requests. Reach for a headless browser when you need real rendering, real interaction, or a vendor nobody has solved. Reach for a scraping API when you would rather not own any of it.
If the proxy half is the part you are still deciding, residential is the tier that clears the reputation gate, ours starts at $0.44/GB pay as you go with no KYC, and sticky sessions cost the same as rotating ones. Before you buy anything, the free checker will confirm an exit is alive and in the country you think it is, which is the cheapest way to rule out the boring failure first.
Sources
- Hyper Solutions: the solver API model, published coverage for Akamai, DataDome, Incapsula and Kasada plus Vercel BotID, the request and response shape, and the acceptable-use and customer-verification policy.
- Hyper Solutions: Akamai Bypass API: the statement that you keep your own proxies, session and cookie jar, and the
ipfield documented as the egress address the payload is generated for. - Hyper Solutions: DataDome Bypass API: datacenter and proxy ranges penalised on sight regardless of payload quality.
- Hyper Solutions: Kasada Bypass API and Incapsula Bypass API: the per-system artefacts each one requires.