/hypersolutions-claude-code
Integrate and debug the Hyper Solutions API for bypassing anti-bot systems — Akamai Bot Manager, Incapsula/Imperva, DataDome, and Kasada. Use when working with the hyper-sdk (Go), hyper-sdk-py (Python), or hyper-sdk-js (JavaScript/TypeScript) SDKs, or calling the
$ npx -y skills add Hyper-Solutions/hypersolutions-claude-code --skill hypersolutions-claude-code --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/hypersolutions-claude-code
Context preview
The summary Claude sees to decide when to auto-load this skill.
Integrate and debug the Hyper Solutions API for bypassing anti-bot systems — Akamai Bot Manager, Incapsula/Imperva, DataDome, and Kasada. Use when working with the hyper-sdk (Go), hyper-sdk-py (Python), or hyper-sdk-js (JavaScript/TypeScript) SDKs, or calling the
SKILL.md
hypersolutions-claude-code.SKILL.mdname: hypersolutions
description: >-
Integrate and debug the Hyper Solutions API for bypassing anti-bot systems —
Akamai Bot Manager, Incapsula/Imperva, DataDome, and Kasada.
Use when working with the hyper-sdk (Go), hyper-sdk-py (Python), or hyper-sdk-js
(JavaScript/TypeScript) SDKs, or calling the *.hypersolutions.co API directly;
when generating sensor data, _abck / reese84 / ___utmvc / datadome cookies,
Kasada x-kpsdk-* tokens, sec-cpt (428) or SBSD (429) payloads, DataDome
interstitial/slider/tags, or Vercel BotID x-is-human headers; and when
debugging blocks, challenges, 403/428/429 responses, TLS fingerprinting, or
header-order problems in request-based scraping. Triggers on: Hyper Solutions,
hypersolutions, hyper-sdk, Akamai sensor, _abck, sec-cpt, sbsd, Incapsula,
reese84, utmvc, DataDome, Kasada, kpsdk, anti-bot bypass,
powhttp, HAR analysis, captured-request debugging, header order.
Hyper Solutions API Integration
What this service does (mental model)
Hyper Solutions is a **payload-generation API**. It does **not** make requests to the target site for you. It takes inputs you collect from the protected site (script contents, cookies, UUIDs, IP, User-Agent) and returns the **sensor data / cookie / token** a real browser would produce. **Your code** is responsible for all the actual HTTP traffic to the target — with a browser-grade TLS client and correct header order.
┌────────────┐ 1. GET page / script ┌──────────────┐
│ Your code │ ──────────────────────────► │ Target site │
│ (TLS │ ◄────────────────────────── │ (Akamai/DD/…)│
│ client) │ 2. HTML, cookies, script └──────────────┘
│ │
│ │ 3. inputs (script, cookies, ip, ua) ┌────────────────────┐
│ │ ──────────────────────────────────────► │ *.hypersolutions.co │
│ │ ◄────────────────────────────────────── │ (this API) │
│ │ 4. generated payload / token └────────────────────┘
│ │
│ │ 5. POST payload back to target ─────► Target site → valid cookie
└────────────┘
If a request is failing, the cause is almost always in **step 1/5 (your TLS client, header order, cookies, or IP)**, not in the generated payload. See `references/debugging.md` first.
Non-negotiable requirements
These apply to **every** product. Standard HTTP libraries (`requests`, `axios`, `net/http`, `fetch`) will be blocked — they have non-browser TLS fingerprints.
1. **Browser-grade TLS client** with a Chrome fingerprint (e.g. `tls-client`, `azuretls-client`, `rnet`/`wreq`, `tlsclientwrapper`). Recommended profile: the **latest Chrome profile your client offers**, with **HTTP/3 disabled** (most proxies don't support it yet) and **random TLS extension order enabled**. 2. **Exact browser header order**, including HTTP/2 pseudo-header order. This is a top fingerprinting signal and DevTools does **not** show the real order. 3. **Session consistency**: the same User-Agent, TLS fingerprint, IP, and header order for the entire flow. A proper cookie jar. Consistent client-hint headers. 4. **Sticky/session proxies, never rotating** — the IP you send to the API must match the IP the target site sees. Pass your outbound IP as the `ip` input (get it from `GET https://ip.hypersolutions.co/ip`). 5. **Match Chrome versions across the board**: UA version, `sec-ch-ua`, and `sec-ch-ua-platform` must agree. Mismatched versions flag automation.
Full detail: `references/tls-and-headers.md`.
Authentication
Every API request needs the `x-api-key` header (get a key at https://hypersolutions.co/keys). Optionally add JWT signing (`x-signature`) for client-side use, or organization headers (`x-app-key` + `x-app-signature`). The SDKs handle all of this for you. Full detail + code: `references/authentication.md`.
Install & construct a session
| Language | Package | Construct | |---|---|---| | Go | `github.com/Hyper-Solutions/hyper-sdk-go/v2` | `hyper.NewSession("api-key")` | | Python | `hyper-sdk` (PyPI) | `Session("api-key")` / `SessionAsync("api-key")` | | JS/TS | `hyper-sdk-js` (npm) | `new Session("api-key")` |
// Go
session := hyper.NewSession("your-api-key").
WithJwtKey("your-jwt-key"). // optional
WithClient(customHTTPClient) // optional# Python (sync) — also SessionAsync with the same signature, methods are awaitable
from hyper_sdk import Session, SensorInput
session = Session("your-api-key", jwt_key=None, app_key=None, app_secret=None)// JS/TS
import { Session } from 'hyper-sdk-js';
const session = new Session("your-api-key", jwtKey?, appKey?, appSecret?, options?);- **Go**: product methods are on the `Session` (e.g. `session.GenerateSensorData(ctx, input)`), take a `context.Context` first, and a pointer to an input struct.
- **Python**: product methods are on the session (e.g. `session.generate_sensor_data(input)`); input classes use keyword args.
- **JS/TS**: product operations are **free functions** taking the session as the first arg (e.g. `generateSensorData(session, input)`); input classes use **positional** constructor args (arg order sometimes differs from field order — see `references/api-reference.md`).
No language SDK? Call the REST API directly — see `references/api-reference.md`.
Which product am I dealing with? (routing)
Identify the anti-bot system, then open the matching reference file.
| System | How to identify it | Reference | |---|---|---| | **Akamai** Bot Manager | `_abck` and `bm_sz` cookies; a `<script src="/xxxx/yyyy/...">` dynamic path near end of body. `428` = sec-cpt challenge; `429 {"t":...}` = SBSD block | `references/akamai.md` | | **Incapsula/Imperva** | Cookie named `reese84` or an `x-d-token` header → reese84. A script like `/_Incapsula_Resource?SWJIYLWA=...` → utmvc. "Pardon Our Interruption" page → reese84 dynamic | `references/incapsula.md` | | **DataDome** | `403`
Read more
name: hypersolutions description: >- Integrate and debug the Hyper Solutions API for bypassing anti-bot systems — Akamai Bot Manager, Incapsula/Imperva, DataDome, and Kasada. Use when working with the hyper-sdk (Go), hyper-sdk-py (Python), or hyper-sdk-js (JavaScript/TypeScript) SDKs, or calling the *.hypersolutions.co API directly; when generating sensor data, _abck / reese84 / ___utmvc / datadome cookies, Kasada x-kpsdk-* tokens, sec-cpt (428) or SBSD (429) payloads, DataDome interstitial/slider/tags, or Vercel BotID x-is-human headers; and when debugging blocks, challenges, 403/428/429 responses, TLS fingerprinting, or header-order problems in request-based scraping. Triggers on: Hyper Solutions, hypersolutions, hyper-sdk, Akamai sensor, _abck, sec-cpt, sbsd, Incapsula, reese84, utmvc, DataDome, Kasada, kpsdk, anti-bot bypass, powhttp, HAR analysis, captured-request debugging, header order.
Hyper Solutions API Integration
What this service does (mental model)
Hyper Solutions is a **payload-generation API**. It does **not** make requests to the target site for you. It takes inputs you collect from the protected site (script contents, cookies, UUIDs, IP, User-Agent) and returns the **sensor data / cookie / token** a real browser would produce. **Your code** is responsible for all the actual HTTP traffic to the target — with a browser-grade TLS client and correct header order.
┌────────────┐ 1. GET page / script ┌──────────────┐ │ Your code │ ──────────────────────────► │ Target site │ │ (TLS │ ◄────────────────────────── │ (Akamai/DD/…)│ │ client) │ 2. HTML, cookies, script └──────────────┘ │ │ │ │ 3. inputs (script, cookies, ip, ua) ┌────────────────────┐ │ │ ──────────────────────────────────────► │ *.hypersolutions.co │ │ │ ◄────────────────────────────────────── │ (this API) │ │ │ 4. generated payload / token └────────────────────┘ │ │ │ │ 5. POST payload back to target ─────► Target site → valid cookie └────────────┘
If a request is failing, the cause is almost always in **step 1/5 (your TLS client, header order, cookies, or IP)**, not in the generated payload. See `references/debugging.md` first.
Non-negotiable requirements
These apply to **every** product. Standard HTTP libraries (`requests`, `axios`, `net/http`, `fetch`) will be blocked — they have non-browser TLS fingerprints.
1. **Browser-grade TLS client** with a Chrome fingerprint (e.g. `tls-client`, `azuretls-client`, `rnet`/`wreq`, `tlsclientwrapper`). Recommended profile: the **latest Chrome profile your client offers**, with **HTTP/3 disabled** (most proxies don't support it yet) and **random TLS extension order enabled**. 2. **Exact browser header order**, including HTTP/2 pseudo-header order. This is a top fingerprinting signal and DevTools does **not** show the real order. 3. **Session consistency**: the same User-Agent, TLS fingerprint, IP, and header order for the entire flow. A proper cookie jar. Consistent client-hint headers. 4. **Sticky/session proxies, never rotating** — the IP you send to the API must match the IP the target site sees. Pass your outbound IP as the `ip` input (get it from `GET https://ip.hypersolutions.co/ip`). 5. **Match Chrome versions across the board**: UA version, `sec-ch-ua`, and `sec-ch-ua-platform` must agree. Mismatched versions flag automation.
Full detail: `references/tls-and-headers.md`.
Authentication
Every API request needs the `x-api-key` header (get a key at https://hypersolutions.co/keys). Optionally add JWT signing (`x-signature`) for client-side use, or organization headers (`x-app-key` + `x-app-signature`). The SDKs handle all of this for you. Full detail + code: `references/authentication.md`.
Install & construct a session
| Language | Package | Construct | |---|---|---| | Go | `github.com/Hyper-Solutions/hyper-sdk-go/v2` | `hyper.NewSession("api-key")` | | Python | `hyper-sdk` (PyPI) | `Session("api-key")` / `SessionAsync("api-key")` | | JS/TS | `hyper-sdk-js` (npm) | `new Session("api-key")` |
// Go
session := hyper.NewSession("your-api-key").
WithJwtKey("your-jwt-key"). // optional
WithClient(customHTTPClient) // optional# Python (sync) — also SessionAsync with the same signature, methods are awaitable
from hyper_sdk import Session, SensorInput
session = Session("your-api-key", jwt_key=None, app_key=None, app_secret=None)// JS/TS
import { Session } from 'hyper-sdk-js';
const session = new Session("your-api-key", jwtKey?, appKey?, appSecret?, options?);- **Go**: product methods are on the `Session` (e.g. `session.GenerateSensorData(ctx, input)`), take a `context.Context` first, and a pointer to an input struct.
- **Python**: product methods are on the session (e.g. `session.generate_sensor_data(input)`); input classes use keyword args.
- **JS/TS**: product operations are **free functions** taking the session as the first arg (e.g. `generateSensorData(session, input)`); input classes use **positional** constructor args (arg order sometimes differs from field order — see `references/api-reference.md`).
No language SDK? Call the REST API directly — see `references/api-reference.md`.
Which product am I dealing with? (routing)
Identify the anti-bot system, then open the matching reference file.
| System | How to identify it | Reference | |---|---|---| | **Akamai** Bot Manager | `_abck` and `bm_sz` cookies; a `<script src="/xxxx/yyyy/...">` dynamic path near end of body. `428` = sec-cpt challenge; `429 {"t":...}` = SBSD block | `references/akamai.md` | | **Incapsula/Imperva** | Cookie named `reese84` or an `x-d-token` header → reese84. A script like `/_Incapsula_Resource?SWJIYLWA=...` → utmvc. "Pardon Our Interruption" page → reese84 dynamic | `references/incapsula.md` | | **DataDome** | `403`
A Claude Code plugin that teaches Claude to integrate and debug the Hyper Solutions anti-bot API (Akamai, Incapsula, DataDome, Kasada) across the Go, Python, and JavaScript/TypeScript SDKs and the raw REST API — and to debug failing requests by inspecting
Repo: Hyper-Solutions/hypersolutions-claude-code

