Covered Hyper Solutions
A solver API builds its payload for one exit IP, so your proxy setup becomes part of the request. Teams often arrive with habits built for rate limiters: rotate hard, rotate often, treat every exit as the same. Point that setup at a solver API and it fails, for one plain reason. Hyper Solutions, which sells solvers for Akamai, DataDome, Incapsula and Kasada, puts the rule on its product pages:
The egress IP the payload is generated for. It must match the IP your target request exits from.
Its code samples call the variable proxy_ip, which says where it expects the value to come from. Once you take that in, most of the setup follows. The upside is real: on its homepage, Hyper Solutions puts one solved flow at 340 KB of traffic against 6.54 MB for a browser.
The three fields every solver wants from you
Each product needs inputs tied to its own challenge: a script, a device-check link, a page URL. On top of that, three identity fields recur, and your proxy setup decides all three.
What each solver needs from your side
| Vendor | Challenge inputs | Identity fields |
|---|---|---|
| Akamai | page URL, _abck, bm_sz, version | user agent (no ip field in the samples) |
| DataDome | device-check link, device HTML | userAgent, ip, acceptLanguage |
| Incapsula | page URL, script content | userAgent, ip, acceptLanguage |
| Kasada | script, domain, IPS link | userAgent, ip, acceptLanguage |
Hyper Solutions' four product pages
That third column is your side of the deal. The user agent, the exit IP and the accept-language have to agree with each other and with what your connection really sends. A solver copies whatever you declare, contradictions included.
The rule everything else hangs off
The IP you declare to the solver must be the IP you exit from, for every request in that session. Rotation stops being a free optimization. It becomes a decision to throw away a trusted session and pay for a new handshake.
Which proxy tier should sit behind a solver API?
Pick the tier for the address check, which comes first. The solver handles the challenge script, but it cannot change the verdict a site reaches before any challenge is served. Hyper Solutions' own DataDome page says it plainly: "Known datacenter and proxy ranges are penalized on sight, regardless of how clean your payload is". So the tier answers the reputation question, and the solver answers the script question. Neither can stand in for the other.
The address check takes one lookup. Our own IP lookup shows the answer for a cloud address, Google's public DNS resolver:
A site that reads "Datacenter / hosting" has its answer before any payload arrives. Run the same lookup on your proxy's exit before you build anything on it.
Which tier suits which job behind a solver API
| Tier | Use it when | Watch for |
|---|---|---|
| Residential, sticky | The default for reading protected pages at volume | Session length has to cover the whole handshake |
| ISP / static residential | Long-lived sessions and anything logged in | Costs more per address, and the address never moves under you |
| Mobile | Targets still flagging you on clean residential | Highest cost per gigabyte; keep it for the stubborn cases |
| Datacenter | Targets with no reputation check worth speaking of | Refused before the solver matters on the four big systems |
| Rotating, per request | Nothing in this workflow | Breaks the payload binding on every request |
Residential held sticky is the default. ISP proxies earn their price when a session has to live for hours or sits behind a login. Their exit runs on always-on hardware and does not drift.
How much traffic does a solver flow use?
Far less than a browser. The comparison on Hyper Solutions' homepage puts one flow through its API at 6 network requests and 340 KB. With Puppeteer or Playwright it lists 281 requests and 6.54 MB. Behind a residential proxy billed by the GB, that gap becomes money:
At the median smallest residential plan in our price records, $3.38 per GB, that is about $22.11 against $1.15 per 1,000 fetches. These are the vendor's own figures, so test them on your target before you budget. Our headless browser bandwidth study runs the same arithmetic at more volumes.
How long should a session last, and how big a pool?
Size the session first. A request is the wrong unit here, and that one change fixes most sizing mistakes.
A trusted session costs a handshake to set up. On Akamai that is a page fetch plus about three sensor posts before the cookie flips; Hyper Solutions' own sample loops three times. We walk through it in how the _abck cookie works. Every one of those round trips is wasted if the exit moves before you finish. So the sticky window has to cover the handshake plus the work you plan for the session, with room to spare.
Sizing a session correctly
- 1
Measure your handshake
Time one full setup against your real target, from first request to trusted cookie. That is your floor, and it runs longer than people expect, because it is several round trips in a row.
- 2
Decide how much work rides on one session
Reading thirty pages on one trusted session spreads the handshake over thirty pages. Reading one page per session pays full price every time, the most expensive way to use a solver.
- 3
Set the sticky window above the sum, with margin
Handshake plus work plus room for a slow answer. Ten minutes suits most reading jobs. Kasada wants longer, because its proof of work changes on every request of a session you want to keep.
- 4
Size the pool from peak concurrency
One session, one address. Count the sessions you need open at once at peak, never your total daily requests. Two workers sharing one exit is two identities on one address, which is the pattern these systems look for.
That last step turns the usual arithmetic around. On a rate-limited target, you size a pool by dividing total requests by a limit per IP. Behind a solver API, you size it by peak concurrent sessions. A job doing a million requests across fifty concurrent workers needs about fifty stable addresses.
How do you read your exit address the right way?
Read it once, in the right order. A small detail here causes an outsized share of failures.
You have to tell the solver your exit IP, so you have to know it. Open the proxy session first, query an IP echo endpoint through that exact session, cache the answer, and only then start generating payloads. Any other order risks describing an address you are not using.
The order that avoids stale addresses
- 1
Open the sticky session
Set up the proxy session that will carry the whole flow, with its session label pinned.
- 2
Read the exit through that session
Hit an IP echo endpoint over the same connection and record what comes back. Our proxy checker shows the same thing when you debug by hand.
- 3
Cache it for the session lifetime
Store the address next to the session label and reuse it for every solver call in that session. Asking again per request buys nothing and costs a round trip.
- 4
Discard address and session together
When the session ends, throw away the cached IP with it. A cached address that outlives its session is the same bug as rotating mid-session, arriving later.
On an endpoint that rotates per request, step two cannot work: the address you measure may differ from the one the next request uses. That is the concrete reason per-request rotation and solver APIs do not mix. Check that your provider can pin a session before you build around one.
How do you keep the whole identity consistent?
The payload describes a client, and so does your connection. Anything the two disagree on is a signal, and the solver copies whatever you told it.
- Accept-language matches the exit country. A German residential exit that sends
en-USis a contradiction you created. Pass the same accept-language to the solver that you send on the wire. - The user agent is identical everywhere. Character for character, in the payload and on every request in the session, sensor posts included.
- Timezone and locale follow the IP if a browser profile runs anywhere in the flow.
- The TLS fingerprint still has to match the browser you claim to be. A solver leaves your handshake as it is. If your client is Python and your user agent says Chrome, the mismatch shows before the payload counts, which is what JA3 and JA4 fingerprinting is about.
You configure
Exit IP and its stability
sticky sessions, one per identity
Geography and language
country, accept-language, timezone
TLS and header order
a real browser handshake from your client
Pacing
jitter and back-off on the first refusal
The solver produces
Sensor and challenge payloads
per vendor, per challenge type
Tokens and headers
x-kpsdk, reese84, interstitial payloads
Proof of work
where the system demands one
How do you test one identity before you scale?
Establish exactly one session, end to end, and confirm each layer on its own. A 403 looks the same whichever layer caused it.
- Confirm the exit is alive and in the right country with the free checker, following how to check if a proxy is working.
- Confirm your TLS fingerprint matches the browser your user agent claims, against a fingerprint test endpoint.
- Confirm the handshake completes. On Akamai, watch the trust cookie actually flip.
- Confirm the address held. Read the exit again at the end of the session. If it moved, your sticky window is too short or your endpoint does not pin.
- Then scale, concurrency before duration, since concurrency is what needs more addresses.
One identity that gets through tells you which layer fails. Buying more proxies tells you nothing, though it is the most common response to a problem that was never about the address.
What is the short version of the setup?
For a residential setup behind a solver API on a typical reading job:
- Sticky sessions with a window well above your measured handshake.
- One address per concurrent session, matched to the market you read.
- Accept-language and user agent identical in the payload and on the wire.
- The exit address read once when the session opens, then cached.
- Rotation only at session boundaries.
Our residential proxies bill by the GB, sticky or rotating alike. Residential Lite costs $0.50 per GB, falling to $0.44/GB at 2,000 GB+. Residential Premium holds a sticky line for 3 to 1,440 minutes, which suits long Kasada sessions, from $1.49 per GB. The free checker verifies an exit before you point anything expensive at it. For the layer above the network, what an anti-bot solver API is covers what the category does and does not do.
What this page could not check
- Vendor figures. The traffic and request counts come from Hyper Solutions' own comparison. We did not measure a solver flow ourselves.
- Akamai fields. The Akamai product page shows code samples only, so we cannot confirm which identity fields its API takes.
- No live targets. We tested no anti-bot system and no proxy network, ours included.
- Terms of use. Solver vendors sell these tools for public data. A site's terms still apply to what you do with them.
- Check by January 22, 2027.
Sources
- Hyper Solutions, DataDome and Incapsula product pages: the ip field, "The egress IP the payload is generated for. It must match the IP your target request exits from.", read October 22, 2026.
- Hyper Solutions, Kasada product page: the ip field, "The IP used to post sensor data to the target site. It must match the target request egress IP.", and proof of work "that changes on every request", read October 22, 2026.
- Hyper Solutions, DataDome product page: "Known datacenter and proxy ranges are penalized on sight, regardless of how clean your payload is.", read October 22, 2026.
- Hyper Solutions, Akamai product page: code samples that post around three sensor payloads before _abck is trusted, read October 22, 2026.
- Hyper Solutions, homepage comparison: 6 network requests and 340 KB per flow against 281 requests and 6.54 MB for Puppeteer or Playwright, read October 22, 2026.
- HProxy price records: median smallest-plan residential price, $3.38 per GB across 68 sellers, captured July 20 to October 22, 2026, headline "from" prices left out.
- HProxy API documentation: Residential Premium sticky sessions of 3 to 1,440 minutes, read October 22, 2026.
- Provenance on the Hyper Solutions material: they sell Akamai, DataDome, Incapsula and Kasada bypass tooling, so they gain when these systems look both strong and beatable. Their technical detail is specific and rare, which is why it stays on this page, but weigh the framing with that interest in mind. Not linked here.
