Documentation
Keys & credentials
Every key the product issues, what each one can do, and where it is allowed to live.
Why there are several
Each key can do exactly one kind of thing, so that the one which inevitably leaks -- the one inside the app binary -- buys an attacker nothing new. Knowing which is which is most of what makes a setup go smoothly.
| Key | What it can do | Where it lives | Where to find it |
|---|---|---|---|
| Public key | Name the app or site an event belongs to. Nothing else. | Page source, the app binary, a tracking link. Anywhere. | App details tab |
| App secret | Sign mobile beacons so a forged install is refused. | Inside the build, from a build-time variable. Never in a source file or a document. | Protection → Beacon signing |
| API key | Post revenue through the Conversions API. | Your server only. Never in an app, never in a browser. | Revenue tab |
| Stripe signing secret | Prove a webhook came from Stripe. | Our side only; you paste it once. | Revenue tab |
| RevenueCat authorization header | Prove a webhook came from your RevenueCat project. | Our side and RevenueCat's. You choose the value. | Revenue tab |
| Play service account | Let us read the amount and buyer of a Play purchase. | Our side only. Account-level: one covers every Android app you ship. | Revenue tab → Play service account |
| Apple In-App Purchase key | Let the app confirm a purchase the moment it happens (optional). | Our side only. Account-level: one covers every iOS app on your team. | Revenue tab → In-App Purchase key |
The app secret, specifically
It is the one that ships on handsets, so it is worth being precise about.
- What a leak costs. Forged beacons: fake installs and opens for this app. Not revenue -- that needs the API key or a store notification, neither of which the app holds.
- What rotating costs. Every build already installed starts sending invalid signatures until users update. Cheap during a beta, expensive once a production build carries it. Rotate deliberately.
- Unsigned is accepted. By default, a beacon with no signature is taken as an old build and accepted; only an *invalid* signature is refused. Reject unsigned beacons is a switch on the Protection tab, and the panel will not let you flip it until the observed signed share is 100%.
- Empty is not absent. Passing
""signs with an empty key and every beacon is rejected. Read the secret so that missing meansnull; every SDK page shows how.
Store connections
The Play service account and the Apple In-App Purchase key are connections on your account, not settings on one app. A Play service account belongs to a Cloud project and an Apple key to a developer team, so either covers every app you ship. Add one once, then select it on each app's Revenue tab.
Their secrets are never shown back. Once saved you see the identifier (the service-account email, the Key ID) and which apps use it, nothing more. Deleting one that an app still uses is refused until you detach it.