Apps and environments
Store identities, app selection, environment attribution, and configuration.
Download this chapterOn this page
A CherrySub app owns its store identities, credentials, API keys, catalog, customers, and purchase data. It can contain an Apple identity, a Google identity, or both. The selected app is visible in the dashboard switcher; confirm it before editing configuration or investigating a purchase.
Add an app
Open Apps → Add app and choose the platforms you support. For Apple, search the public App Store listing by name or supported store identifier, select the correct match, and review the populated details. If the app is not public yet, enter its identifiers manually. Changing the search removes stale match selection; review the final bundle and app ID before saving.
For Google, enter the exact package name. Choosing both platforms requires both store identities. Your display name can differ from the public store name.
| Field | Purpose |
|---|---|
| App name | A label in CherrySub; it does not rename the store listing |
| Apple bundle ID | Matches the signed bundle in Apple purchases and notifications |
| Apple App ID | The numeric App Store identifier; production verification also checks this signed value |
| Google package name | Identifies the application used for Android Publisher reads |
Creating an app in CherrySub does not create its App Store Connect record, Play Console app, store products, tax agreement, or storefront purchase UI.
Save the first keys
The hosted app-creation flow displays one secret key and one publishable key. Copy them before leaving the result screen. Plaintext is not available from the later list.
Use iap_sk_ only on your server. Use iap_pk_ in the client SDK with a short-lived customer token. If you lose a key, create another and revoke the lost one as needed. Key lifecycle.
Inspect and edit app details
Open an app from the Apps list to review store identities, safe key hints, integration status, and the catalog. Use Edit app to update supported identity/name fields. An app-specific detail can be opened without making it the selected reporting app; use its selection action when you want the rest of the dashboard to follow it.
Changing a store identifier does not rewrite old signed purchases. Treat it as a configuration change that must match the actual store app. For a different product or deployment boundary, creating a separate app is usually the clearer integration path.
The dashboard shows whether an app is enabled. Root administration can soft-disable an app: attribution and key authentication stop, keys are revoked, queued webhook work is cancelled, and history remains stored. That is not deletion of its ledger. Admin API.
Two different environment choices
Deployment environment chooses the CherrySub installation: for example, staging API and staging dashboard versus a separately configured production installation. Keys and database state belong to that installation.
Store environment is verified purchase attribution inside an installation: sandbox, production, or, where the evidence does not yet establish it, unknown.
Changing a dashboard filter changes what you inspect. It does not turn a purchase into production or move credentials to another deployment. Apple signs the environment. Google RTDN arrives without a purchase environment, so the notification can be unknown until the authoritative purchase read establishes it. Unknown is never silently counted as production.
App identity is not a store connection
A bundle ID or package name alone does not configure the server credential. Complete the corresponding App Store or Google Play setup. A saved credential also does not prove notification wiring or a successful purchase; the test matrix supplies that proof.
If a connection page says Add your store identifier, follow Open app settings, add the missing identity, and return to that store. If there is no selected app, add or select one first.