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

# Sessions

> A BMP session is one phone: its identity, its cookies, its IP and its handshake, kept together for as long as the app accepts it.

With Akamai BMP you are not sending a sensor; you are being a phone. Roolink emulates that phone when it generates the sensor, and every request you make afterwards has to look like it came from the same one. This page is about keeping that story straight.

## What makes up a session

| Part            | Where it comes from                                                                                                           | Rule                                                                                                                                     |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Device identity | `deviceId` and the device fields in the sensor response: OS version, hardware identifier, app version, screen size, language. | Use these values wherever the app's headers describe the phone. Never mix values from two responses.                                     |
| Cookies         | The `cookies` array in the sensor response, then whatever the app's servers set afterwards.                                   | Seed your jar from the response on the first call and keep the jar for the life of the session.                                          |
| IP address      | The `proxy` you send Roolink.                                                                                                 | The same sticky proxy for the Roolink call and for every request to the app. Akamai binds the device to the IP during the SDK handshake. |
| TLS handshake   | The [profile](/akamai-bmp/tls-profiles) you chose for the device's OS version.                                                | Create the client once and keep it. Changing the profile mid-session ends the session.                                                   |

Change any one of the four and Akamai sees a different phone. That is the most common cause of a block that appears "for no reason".

## Reusing a device

Pass the `deviceId` from a previous response on your next `/sensor` call, together with the same `app`, and Roolink continues that device: same identity, same cookies, same SDK state. Reuse is faster than starting fresh and produces a fingerprint Akamai has already seen behave.

Two things to know:

* `deviceId` is platform-specific. An iOS `deviceId` cannot be reused for an Android request or the other way round.
* On a reuse, the cached app, proxy, language and iPad setting stay in effect. Fields you send alongside `deviceId` are recorded for a fresh device only.

## How long a device lives

Roolink keeps a device in its cache for a short time after each use, and every use resets the clock. A device you keep using stays alive; a device you leave alone expires.

If you pass a `deviceId` that is no longer cached, Roolink does not fail. It initializes a new device and gives it the identifier you supplied, so your bookkeeping still works but Akamai sees a new phone. If you rely on continuity, keep the device warm by using it.

## When to reuse and when to rotate

Keep using a device until the app blocks it. A block on a device that has worked is a signal about that device, that IP or that account, not about your integration. Then retire the device, take a fresh sticky proxy session, and start a new one with no `deviceId`.

Start a new device, rather than reusing one, when you:

* change proxy or region;
* switch accounts on the app, if the app ties devices to accounts;
* have not used the device for longer than its cache lifetime.

Running several devices in parallel is fine. Each is its own bundle: its own `deviceId`, its own jar, its own proxy session, its own client.

## Sensors within a session

The sensor is not part of the bundle; it is the thing the bundle produces. We recommend generating a fresh one for each protected request the app makes, and always passing the current `deviceId` so the session continues rather than starting over.