Skip to main content
An app on a phone does not connect like Chrome. Akamai’s mobile SDK checks the TLS handshake and the HTTP/2 settings of every request, and the sensor Roolink returns is built for a device that connects one specific way. Your client has to connect the same way or the sensor is wasted. This page names the profiles for each platform and shows how to load them in each language. Everything else about the request, the headers and their order, comes from a capture of the real app, exactly as it does for a website; see Capture requests with powhttp.

iOS

iOS apps built with Akamai’s SDK connect with one of two handshakes, which we call Standard and Secondary. The handshake also changes between iOS releases, so the profile you pick depends on the ios version in the sensor response. Start with the Standard profile for the row that matches your device. If the app rejects the session even though the sensor is fresh and the cookies are right, switch to the Secondary profile and try again. Note which one an app accepts so you do not repeat the experiment. The profiles ship in one repository, roolinkio/tlsprofiles, in two forms that produce the same handshake: a Go module for Go, and a profiles.json file that Python and Node hand to the tls-client shared library as a custom client. All three TLS clients in these docs wrap that library, and we check the three against each other: same JA3, same JA4, same HTTP/2 fingerprint for every profile.
Two details matter in Python and Node. The profiles fix their own extension order, so extension randomization must be off; Node turns it on by default. And the Python library builds its custom-client payload for an older shared library, so AppSession sets the ALPN list and the certificate compression list in the shape the current one expects. Without those two lines the connection negotiates no ALPN and the handshake is refused.

Android

Android apps built with Akamai’s SDK use OkHttp, and the tls-client engine ships a matching preset in every language. No profile file is needed.

Keep the profile for the life of the session

A BMP session is the device Roolink emulated, the cookies it earned, the IP it used and the handshake it connected with, all together. Changing the TLS profile in the middle of a session is the same as changing phones: the session ends. Choose the profile when you create the client and keep that client for as long as you keep the deviceId. Sessions covers the rest of the bundle.

Check your handshake

Route your client through powhttp and compare its TLS handshake with a capture of the real app from a phone on the same network. The cipher list, the extension order and the HTTP/2 settings should match. If you do not have the app capture, a fingerprint echo such as https://tls.peet.ws/api/all at least confirms that the profile you selected is the one your client is actually using. For reference, SecondaryIOS26_2 reports the JA4 t13d2013h2_a09f3c656075_7f0f34a4126d and the Standard iOS 26 profiles report t13d1313h2_f57a46bbacb6_7f0f34a4126d, in every language.