What you will build. A small script that loads a protected page the way a browser does, asks Roolink for the sensor the page expects, posts it back, and ends with a cookie the site trusts. That cookie is what lets your next request through.
What you need. A Roolink account with an API key, a residential proxy that keeps the same IP for a session, powhttp installed, and Python, Go or Node. Pick your language in any code block; every block on the page follows.
Copy your API key from the dashboard and put it in an environment variable, along with your proxy URL. Then install two packages: the Roolink SDK, which talks only to Roolink, and a TLS client, which talks to the target site.
Open powhttp, start recording, and load your target page in Chrome. Keep that recording open. Every request you make below has a matching one in it, and you will copy the headers from there.
Start the way a person would: open the page that comes before the protected action. For a shop, that is the product page before add to cart. Send it through your proxy with the headers Chrome sent for that page in your powhttp recording, in the same order.
Two things come back. The response sets the _abck and bm_sz cookies, and the HTML contains one <script> tag whose path looks random, near the end of the body. That path is different for every site and changes over time, so read it from the page each run.
You should see a 200 and a script path such as /aB3dE/fG7/hI/jK/LmNoPqRsTuVwXyZ.
Download the script through the same session, using the headers from the script request in your recording. Then hand its body to Roolink’s /parse endpoint. Roolink reads the site’s configuration out of the script and returns a small object, called the script data, that every sensor for this site needs.
The result stays valid until the site changes its script, so cache it and reuse it across sessions.
You should see an object with ver, key, dvc and din fields.
Now ask Roolink for the sensor. Send the page URL, the same User-Agent your session uses, the current _abck and bm_sz cookies, the script URL and the script data. Set stepper to true and pass the attempt number as index, starting at 0: that way each sensor continues the same visitor’s timeline instead of starting a new one. Roolink returns one long string.
Post that string to the script path on the site, wrapped as {"sensor_data": "..."} with a text/plain content type. The site replies {"success": true} and sends back an upgraded _abck cookie.
Check the cookie. If it contains ~0~, you are through. If it still contains ~-1~, generate and post another sensor with the new cookie values. Three posts is the ceiling: if the cookie has not flipped by then, the problem is the connection, not the sensor. Start with Troubleshoot a block.
You should see {"success": true} from the site and a _abck value containing ~0~.
Use the same session for the request you came for. Nothing changes except that the site now trusts your _abck cookie.
Most sites invalidate the cookie after a protected action, so repeat step 4 before the next one. The script data from step 3 does not need to be fetched again.
You should see a 200. That is your first solved challenge.
The complete file
The whole program in one file. The three header sets are left for you to fill from your powhttp recording: one for the page, one for the script, one for the sensor post. Copy each list in the order powhttp shows it. Header order matters as much as the values, and it is the one thing this guide will not give you, because your capture is always more current than any list here.If something goes wrong
The very first page request is blocked or returns an Akamai error page
The very first page request is blocked or returns an Akamai error page
Roolink answers 401
Roolink answers 401
x-api-key header is missing or the key is wrong. Check the environment variable and that the SDK was created with it.Roolink answers 422 with no device profile for user agent
Roolink answers 422 with no device profile for user agent
The site says success but _abck never contains 0
The site says success but _abck never contains 0
sec-fetch-* values are the usual culprits. Some sites never flip the cookie to ~0~; on those, post three sensors and proceed to step 5.The protected request fails even though _abck is valid
The protected request fails even though _abck is valid
_abck.