Skip to main content
Roolink does not invent a browser. Every Akamai Web payload is built from a real device profile collected from a real browser on real hardware, chosen to match the User-Agent you send. That is what makes the payload consistent with the rest of your request. It also means the User-Agent has to be one Roolink has a profile for, and that the rest of your request has to describe the same browser. Akamai BMP is different: it emulates an app on a device Roolink controls, and you do not send a browser User-Agent at all.

​
What to send

For the best odds, use the User-Agent that current stable Google Chrome on Windows or macOS reports. That is what Roolink tests against and what the largest share of profiles come from. Firefox, Safari and Edge User-Agents work the same way when a profile exists; send the exact string the browser reports. Chrome has reported a reduced User-Agent since version 101, so the string is the same for everyone on a platform and changes only with the major version:
Windows
macOS
Replace 152 with the current stable major. Chrome’s own release schedule shows it. If Roolink answers 422 for the newest release in the first days after it ships, use the previous major until the pool catches up.

​
Keep everything describing the same browser

The User-Agent is one of several places your request describes the browser. Bot protection compares them, and a payload built for one browser sent by a client describing another is a clear signal. A quick habit that catches most mismatches: print the User-Agent, the client hint headers and the TLS profile name at startup and read them together. They should describe one browser.

​
The error you get otherwise

Akamai Web answers 422 with no device profile for user agent. It means the string you sent is not one Roolink has a profile for. Check for a typo first, then check the major version, then try the other desktop platform.