For the complete documentation index, see llms.txt. This page is also available as Markdown.

Core Requirements

The non-negotiable requirements that apply to every Hyper Solutions integration, regardless of which anti-bot system you're bypassing.

These five requirements apply to every product. If any one of them is wrong, you will be blocked no matter how good the generated payload is. Standard HTTP libraries (requests, axios, net/http, fetch) fail all of these by default, they have non-browser TLS fingerprints and no control over header order.

Every vendor guide assumes you already meet these, so it's worth getting them right once, here.

1. Browser-grade TLS client

Use an HTTP client that reproduces a real Chrome TLS handshake, for example tls-client or azuretls-client. Configure it with:

  • The latest Chrome profile your client ships (a slightly older profile is acceptable, see User Agents).

  • HTTP/3 disabled: most proxies don't support it yet.

  • Random TLS extension order enabled.

Full detail: TLS Fingerprinting.

2. Exact browser header order

Header order (including the HTTP/2 pseudo-header order (:method, :authority, :scheme, :path for Chrome)) is one of the strongest fingerprinting signals. Browser DevTools does not show the real order, so never copy header order from it. Capture it with a proxy that preserves the wire order instead.

Full detail: Header Order.

3. Session consistency

Keep the same User-Agent, TLS fingerprint, IP address, and header order for the entire flow, backed by a proper cookie jar. Your client-hint headers (sec-ch-ua, sec-ch-ua-platform) must stay consistent too. Mixing values mid-session is a reliable way to get flagged.

4. Sticky proxies, never rotating

The IP you send to the API must match the IP the target site actually sees. Rotating proxies issue a new IP per connection, so the API generates a payload for one IP while the target sees another, and you get blocked. Use sticky/session proxies, and pass your outbound IP (from GET https://ip.hypersolutions.co/ip) as the ip input.

Full detail: IP.

5. Matched Chrome versions

The Chrome version in your User-Agent, your sec-ch-ua header, and your sec-ch-ua-platform must all agree. A User-Agent claiming one version with client hints from another is an obvious automation signal. Update them together whenever you bump the version.

Full detail: User Agents.

Replay, don't hardcode. Most generate endpoints return a headers object of client hints. Replay those on the target site rather than hardcoding your own, hardcoded hints from a stale browser capture are a common cause of blocks.

Still blocked?

If you meet all five and are still blocked, the fault is almost always in the request rather than the payload. Work through the Claude Code plugin or capture your traffic with powhttp to see exactly what went on the wire.

Last updated