Teams that adopt a solver API usually arrive with proxy habits built for a different opponent. Rate limiters reward spreading traffic across as many addresses as possible, so that is the reflex: rotate hard, rotate often, treat any exit as interchangeable with any other. Point that configuration at a solver API and it underperforms badly, for one specific reason that is easy to state and easy to miss.
The payload a solver returns is generated for a single exit address. It is not a generic key. Hyper Solutions documents the ip field on every one of their four products in almost identical words:
The egress IP the payload is generated for. It must match the IP your target request exits from.
Their SDK examples name the variable proxy_ip, which is about as direct a statement as documentation gets about where they expect that value to come from. Once you internalise that, most of the configuration follows.
The three fields every solver wants from you
Reading across all four of their products, the inputs split cleanly. Each vendor needs something specific to its own challenge, the script content, a device-check link, an IPS link, the current cookies. But every one of them asks you for the same three identity fields, and those three are the ones your proxy configuration decides.
What each solver needs from your side
| Vendor | Challenge-specific inputs | Identity fields |
|---|---|---|
| Akamai | pageUrl, scriptUrl, current _abck, bm_sz, version | userAgent, ip, acceptLanguage |
| DataDome | device-check link, device HTML | userAgent, ip, acceptLanguage |
| Incapsula | pageUrl, script content, script URL | userAgent, ip, acceptLanguage |
| Kasada | script, IPS link | userAgent, ip, acceptLanguage |
Input fields per Hyper Solutions' four product pages
That third column is the contract you are responsible for. The user agent, the exit IP, and the accept-language have to agree with each other, and all three have to match what your connection actually presents. A solver reproduces faithfully whatever you declare, including the contradictions.
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 is no longer a free optimisation. It is a decision to throw away a trusted session and pay for a new handshake.
Pick the tier for the gate, not the challenge
The solver handles the challenge. It cannot argue with the verdict that gets reached before any challenge is served. DataDome's own documentation is direct about this: datacenter and proxy ranges are penalised on sight, regardless of how clean the payload is. So the tier you buy is answering the reputation question, and the solver is answering the script question, and neither substitutes for the other.
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; reserve it for the stubborn cases |
| Datacenter | Targets with no reputation gate worth speaking of | Refused before the solver is ever consulted on the four major systems |
| Rotating, per request | Nothing in this workflow | Breaks the payload binding on every request |
Residential held sticky is the honest default. ISP proxies earn their premium when a session has to live for hours or sits behind a login, because the exit is on always-on hardware and does not drift.
Size the session, then size the pool
The unit of work here is the session, not the request, and that single change fixes most sizing mistakes.
A trusted session costs you a handshake to establish. On Akamai that is a page fetch plus roughly three sensor posts before the cookie flips, which we walk through in how the _abck cookie works. Every one of those round trips is wasted if the exit moves before you have finished. So the sticky window has to comfortably exceed handshake time plus the work you intend to do afterwards.
Sizing a session correctly
- 1
Measure your handshake
Time one full establishment against your real target, from first request to trusted cookie. This is your floor, and it is longer than people expect because it is several sequential round trips, not one call.
- 2
Decide how much work rides on one session
Reading thirty pages on one trusted session amortises the handshake thirty ways. Reading one page per session pays full price every time, which is the most expensive way to use a solver.
- 3
Set the sticky window above the sum, with margin
Handshake plus work plus headroom for a slow response. Ten minutes suits most reading workloads. Kasada wants longer, because it computes a fresh proof of work per protected request on a session you would rather keep.
- 4
Size the pool from peak concurrency
One session, one address. Count the sessions you need open simultaneously at peak, not your total daily requests. Two workers sharing one exit is two identities on one address, which is exactly the clustering pattern these systems look for.
That last point is worth restating because it inverts the usual arithmetic. On a rate-limited target you size a pool by dividing total requests by a per-IP ceiling. Behind a solver API you size it by peak concurrent sessions, and a job doing a million requests across fifty concurrent workers needs about fifty stable addresses, not a million rotations.
Read your exit address, once, in the right order
A small implementation detail that causes a disproportionate share of failures.
You have to tell the solver your egress IP, which means you have to know it. The correct sequence is to open the proxy session first, query an IP echo endpoint through that exact session, cache the answer, and only then start generating payloads. Doing it in any other order risks describing an address you are not actually using.
The order that avoids stale addresses
- 1
Open the sticky session
Establish the proxy session that will carry the whole flow, with its session identifier 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 interactively when you are debugging by hand.
- 3
Cache it for the session lifetime
Store the address alongside the session identifier and reuse it for every solver call in that session. Re-querying 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 outliving its session is the same bug as rotating mid-session, arriving later.
On a per-request rotating endpoint, step two is unreliable by construction: the address you measure is not necessarily the address the next request uses. That is the concrete reason per-request rotation and solver APIs do not combine, and it is worth checking your provider can pin a session before you build around one.
Make the whole identity agree
The payload describes a client. Your connection describes a client. Anything the two disagree about is a signal, and the solver faithfully reproduces whatever you told it.
- Accept-language matches the exit country. A German residential exit sending
en-USis a contradiction you introduced. Pass the same accept-language into 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, including the sensor posts.
- Timezone and locale follow the IP if you are also driving a browser profile anywhere in the flow.
- The TLS fingerprint still has to match the browser you claim to be. A solver does not fix your handshake. If your client is Python and your user agent says Chrome, the mismatch is read before the payload is considered, which is what JA3 and JA4 fingerprinting is about.
You configure
- Exit IP and its stabilitysticky sessions, one per identity
- Geography and languagecountry, accept-language, timezone
- TLS and header ordera real browser handshake from your client
- Pacingjitter and back-off on the first refusal
The solver produces
- Sensor and challenge payloadsper vendor, per challenge type
- Tokens and headersx-kpsdk, reese84, interstitial payloads
- Proof of workwhere the system demands one
Prove one identity before you scale
The cheapest debugging you will ever do happens before the job runs. Establish exactly one session, end to end, and confirm each layer separately, because a 403 looks identical whichever layer produced 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, that means watching the trust cookie actually flip rather than assuming it did.
- Confirm the address held. Read the exit again at the end of the session and check it is the address you started with. If it moved, your sticky window is too short or your endpoint is not pinning.
- Then scale, and scale concurrency before you scale duration, since concurrency is the axis that needs more addresses.
Getting a single identity through tells you which layer is failing. Buying more proxies tells you nothing, and is the most common response to a problem that was never about the address.
The short configuration
For a residential setup behind a solver API, on a typical reading workload: sticky sessions with a window comfortably above your measured handshake, one address per concurrent session, geo-matched to the market you are reading, accept-language and user agent identical between the payload and the wire, exit address read once at session open and cached, and rotation only at session boundaries.
Ours runs $0.44/GB pay as you go with no KYC, sticky sessions cost the same as rotating ones, and the free checker will verify 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 cover.
Sources
- Hyper Solutions: the
ipfield documented as the egress address a payload is generated for, and the requirement that it match the exit IP of the request to the target. The same field appears on their DataDome, Incapsula and Kasada products. - Hyper Solutions: DataDome Bypass API: datacenter and proxy ranges penalised on sight regardless of payload quality.
- Hyper Solutions: Kasada Bypass API: a fresh proof-of-work value required per protected request.