Leanplum's user guides and developer documentation.

Securing your Leanplum API keys

Leanplum uses client keys for authentication when using the API. Authentication is done by adding the appropriate clientKey and appId directly in the requests. Additionally, all data is encrypted in transit over TLS and HTTPS.

Your keys are located in App Settings in the Leanplum dashboard.

Your keys are located in App Settings in the Leanplum dashboard.

Using the right keys

Each app has a set of keys, and each key has different permissions associated with it. For example, you'll see a Development key, a Production key, a Data Export key, etc.

  • The Production key is the only one you should use in a live, production app — it contains the most limited set of permissions and is meant to be used when sending production data to Leanplum.
  • The Development key is designed to be used in tightly-controlled development environments. It has a higher level of permissions associated with it and must never be used to send production traffic to Leanplum.

See Using the right API keys for more on when to use a production build versus a development build.

Securing your keys

You should keep your keys private and never bundle/ship them with any app. The only exception is the Production key, which you may need to bundle with the app, depending on your implementation. If you choose to bundle the Production key, you should put all possible measures in place to obfuscate the key for storage.

Leanplum follows industry standard best practices for managing API keys. The appId and the Production clientKey can be sent as part of the body of the request (which is what the Leanplum Android and iOS SDKs do). Because traffic goes through HTTPS, the payload is encrypted and therefore not sniffable.

Avoid sending sensitive data in query parameters

Query parameters aren't encrypted when using HTTPS — only the body of the request is encrypted. For this reason, you should not send keys using query parameters. Just encoding the keys (e.g. base64) in areas that don't get encrypted offers no security, as they can be trivially decoded. That's why you should always send keys in the body of post requests over HTTPS.

Implement measures against app binary attacks

If you bundle the Production key with your app, there is some risk that a person could download your APK or app binary and decompile it to obtain the key. Most vendors offering products like Leanplum and their clients accept this level of risk. This is another reason you should never ship any keys other than the Production key with your application.

To minimize the risk of exposing the key against the app binary decompilation attack, you should seriously consider implementing some additional security measures.

For example, you could choose to manage the keys yourself by not bundling the Production clientKey with your app. Your app could talk to another service hosted and maintained by you to obtain your Leanplum Production key (over a secure connection), then use it to make calls to Leanplum. This won't eliminate your risk completely, but it may reduce your risk of someone stealing your key.

Leanplum does not provide any services for obtaining the keys at runtime or for obfuscating the keys or the app binaries — it is up to you to create or obtain these services.

Reissue keys

In the rare case that you suspect a malicious third party has obtained access to your Production key, or if you have any reason to believe that your Production key has been compromised, you should deactivate that key, issue a new Production key and update your apps with it. You can do this in App Settings under Keys & Settings.

A Production clientKey and appId pair is not sufficient to modify/access all of your data. Any calls with the Production key will only be able to modify information for a single user (and the attacker must also know the User Id, which is unlikely if you're using random UUIDs for user ids).

Securing your Leanplum API keys


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.