Skip to main content

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.

1Set up

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.

The TLS client is not optional. Akamai fingerprints the connection and the exact order of your headers before the sensor matters. The libraries below are the ones we recommend; Set up your HTTP client explains each setting.
2Load the page and find the script

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.

3Fetch and parse the script

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.

4Generate the sensor and post it

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~.

5Make the protected request

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

Roolink is not involved yet. This is the connection itself: an HTTP library that does not look like Chrome, headers in the wrong order, or a proxy that changed IP. Route your script through powhttp and compare its requests with Chrome’s from your recording, header by header. Troubleshoot a block matches each symptom to its cause.
The sensor was accepted but the connection is not trusted. Compare your page, script and sensor requests with Chrome’s in powhttp; header order and the 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.
Check whether the site also runs SBSD, Sec-CPT or a pixel request in a browser; each has its own guide under Akamai Web. Confirm the IP did not change between steps, and keep every cookie the site set, not only _abck.

Next steps

Troubleshoot a blockWhich layer said no first, and what to change.
Sensor dataThe flow in depth: cookies, script rotation, stepper mode and every field.
SBSDThe second check many Akamai sites run alongside the sensor.
Sec-CPTThe proof-of-work challenge behind a 428.