Skip to main content
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

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.