> For the complete documentation index, see [llms.txt](https://docs.hypersolutions.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hypersolutions.co/start-here/core-requirements.md).

# Core Requirements

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`](https://github.com/bogdanfinn/tls-client) or [`azuretls-client`](https://github.com/Noooste/azuretls-client). Configure it with:

* The **latest Chrome profile** your client ships (a slightly older profile is acceptable, see [User Agents](/api-reference/user-agents.md)).
* **HTTP/3 disabled**: most proxies don't support it yet.
* **Random TLS extension order enabled.**

Full detail: [TLS Fingerprinting](/request-based-basics/tls-fingerprinting.md).

### 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](/request-based-basics/header-order.md).

### 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](/request-based-basics/ip.md).

### 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](/api-reference/user-agents.md).

{% hint style="info" %}
**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.
{% endhint %}

### 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](/ai-plugins/claude-code-plugin.md) or capture your traffic with [powhttp](/request-based-basics/installing-powhttp.md) to see exactly what went on the wire.