> ## Documentation Index > Fetch the complete documentation index at: https://docs.roolink.io/llms.txt > Use this file to discover all available pages before exploring further. # Sensor data > The core Akamai Web flow in depth: what the cookies mean, how the script rotates, when to post again, and what each field does. The [Quickstart](/akamai-web/quickstart) walks through the sensor flow once. This page explains the pieces so you can run it reliably, on any site, for as long as you need. ## The two cookies Akamai sets two cookies on the first response and reads them on every request. | Cookie | What it is | What to do with it | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | `_abck` | The trust cookie. Contains `~-1~` while Akamai does not trust the visitor and `~0~` once it does. Changes after every sensor post and after most protected actions. | Send its current value to `/sensor` every time. Read it back from the jar after each post. | | `bm_sz` | A session identifier tied to `_abck`. | Send its current value to `/sensor` every time. Never edit it. | Send every other cookie the site sets as well, exactly as a browser would. Keeping one cookie jar per session does this for you. ## The script and its data The page contains one script tag whose path is unique per site and changes over time. Read it from each page response, fetch it through the same session, and send its body to `/parse`. The result, called the **script data**, is a small object with four fields: `ver`, `key`, `dvc` and `din`. Every sensor for this site needs it. The result stays valid for as long as the site serves the same script. Cache it on your side keyed by the script URL, and refresh it when the URL changes. Nearly every site today runs sensor version 3, which needs the script data. On the rare site still on version 2, omit `scriptData` from the sensor request. ## Generating and posting Call `/sensor` with the page URL, your User-Agent, the two cookies, the script URL and the script data. Post the returned string to the script path as `{"sensor_data": ""}` with a `text/plain;charset=UTF-8` content type and the page as referer. Akamai answers `{"success": true}` and sets a new `_abck`. Then read `_abck`: * **It contains `~0~`.** You are trusted. Make the protected request. * **It still contains `~-1~`.** Generate and post another sensor with the new cookie values. Stop after three posts. If the cookie has not flipped, the sensor is not the problem; the connection is. Work through [Troubleshoot a block](/troubleshoot). A few sites never flip the cookie to `~0~` and still accept the protected request after three posts, so make the request anyway before concluding you are blocked. ## After the protected action Most sites invalidate `_abck` when you complete a protected action such as adding to cart or logging in. Expect to run the generate-and-post cycle again before the next one. You do not need to fetch or parse the script again unless its URL has changed. ## Request fields | Field | Required | What it does | | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `url` | yes | The page the sensor is for, with `https://`. Use the page a user would be on before the protected action. | | `userAgent` | yes | The User-Agent your session sends to the site. It must be one Roolink has a profile for; see [Supported browsers](/supported-browsers). | | `_abck` | yes | Current `_abck` from your jar. Empty string on the first request if the site has not set it yet. | | `bm_sz` | yes | Current `bm_sz` from your jar. | | `scriptUrl` | yes | Absolute URL of the script you fetched. | | `scriptData` | yes for v3 | The object `/parse` returned for this script. | | `language` | no | The `Accept-Language` you send the site, in whichever form you use it: `en-US` or `en-US,en;q=0.9`. Keep it consistent with your proxy's region. | | `stepper` | recommended | Set it to `true` on every call. Each sensor then continues the same visitor's timeline. See below. | | `index` | with stepper | Position of this sensor in the session: `0` for the first post, then `1`, `2`. | | `keyboard` | no | Include typing events. Use on pages where a person would type before the action, such as login or search. | | `sec_cpt` | no | Set when the page served a Sec-CPT challenge in this session. | | `flags` | no | Site-specific flags. Only set when support asks you to. | ## Stepper mode Set `stepper: true` on every `/sensor` call and pass `index` starting at `0` and increasing by one per post. In this mode the sensors in a session describe one continuous visit: the first covers arriving on the page, the next covers what happens after the first post, and so on. It is how our own tooling runs, and it is what the Quickstart does. Without `stepper`, each call produces a complete, self-contained sensor and `index` is ignored. That is fine for a single post, but sites that read the second or third sensor notice when each one starts from scratch. ## Troubleshooting Roolink builds sensors from real browser profiles and needs a User-Agent it has one for. Current desktop Chrome on Windows or macOS is the safe choice; send the identical string to the site. See [Supported browsers](/supported-browsers). The body was not a complete Akamai script. Send the script exactly as fetched, as `text/plain`, without trimming or re-encoding. The post itself is being refused, so the sensor never reached Akamai. Check that you post to the current script path, with the page as referer and `text/plain;charset=UTF-8` as content type, through the same session that loaded the page. Expected after a protected action. If it happens on a plain page load, the IP changed or the User-Agent differs between requests. The site runs a second layer. Look for the SBSD script, a `429` with a token, a `428` response, or the pixel variables, and read the matching guide. Also confirm the `bm_sv` and any other cookies from earlier responses are still in the jar.