# Connect the App Store

Apple connection has three parts: matching your app identity, storing an In-App Purchase credential for server API work, and receiving App Store Server Notifications V2. A successful credential save does not complete the other two parts.

## Before you start

Have an App Store Connect app record, its bundle ID, its numeric App Store app ID for production, and an Apple account permitted to manage In-App Purchase keys. Create the store products and complete the relevant store agreements and availability settings before testing purchases.

In CherrySub, select the correct project and app. If the bundle ID is missing, use the connection page's **Open app settings** recovery action.

## Guided CLI setup

```sh
cherrysub auth login
cherrysub setup apple APP_UUID --project PROJECT_UUID
```

The command signs in directly to Apple, handles 2FA, lets you select a team, checks that the bundle exists in that team, checks key access, and asks before creating the In-App Purchase key. The key is uploaded directly to CherrySub. Your Apple password and Apple session cookies are not saved to a CLI profile.

Use `--sms` for SMS verification or `--team-id` to choose an explicit App Store Connect provider. `--dry-run` prints the CherrySub-side plan without signing in to Apple. Existing app credentials are kept unless `--rotate` is provided. The CLI never automatically revokes old Apple keys.

See the [complete CLI reference](/docs/cli) for installation, scripting, and recovery from a partially completed setup.

## Upload an existing key

1. Open **Users and Access → Integrations → In-App Purchase** in App Store Connect.
2. Generate/download the In-App Purchase `.p8` key and copy its Key ID and Issuer ID.
3. In CherrySub, open **Integrations → App Store → Upload credential**.
4. Choose the `.p8` file. Recognized `SubscriptionKey_ID.p8` or `AuthKey_ID.p8` filenames populate Key ID.
5. Review or enter the Key ID, paste the Issuer ID, and save.

The file limit is 16 KiB. Pasting the complete PEM is available under **Paste key instead**. Use an In-App Purchase key: a general App Store Connect API key can have a similar PEM format but serves a different purpose. Apple permits a one-time private-key download. [Apple's key instructions](https://developer.apple.com/help/app-store-connect/configure-in-app-purchase-settings/generate-keys-for-in-app-purchases).

## Configure server notifications

In the app's App Store Connect settings, configure App Store Server Notifications **Version 2**. For this staging installation, the sandbox notification URL is:

```text
https://api-staging.cherrysub.com/ingest/apple/assn
```

For another deployment, use its own HTTPS API origin with `/ingest/apple/assn`. Configure sandbox and production destinations deliberately. Apple can send sandbox notifications to the production URL when no sandbox URL is configured, so do not rely on an empty sandbox field as isolation. [Apple's notification URL instructions](https://developer.apple.com/help/app-store-connect/configure-in-app-purchase-settings/enter-server-urls-for-app-store-server-notifications/).

Do not add a CherrySub app API key to this store notification URL. Apple authenticates the payload through its signed evidence. CherrySub verifies the chain, certificate purpose, ES256 signatures, and OCSP status, independently verifies nested signed data, and checks the signed app identity and environment.

## Verify the complete connection

Refresh the connection page after CLI setup. Confirm the app credential's safe hint, then send a store-backed sandbox purchase through your SDK. Inspect its transaction and customer access in the same app/environment.

A notification test proves notification transport, not a paid purchase or working access mapping. Receipt validation can be available independently of Apple server API history credentials; avoid treating every capability as one universal green connection flag.

Xcode-local StoreKit testing is not proof that server-side Apple-chain verification works. Use the store-backed sandbox path for the end-to-end check. Missing/invalid signatures are rejected, and an unavailable certificate-status responder is a transient failure for retry, not a verification bypass.

## Rotate or disconnect

Upload a replacement or explicitly run CLI setup with `--rotate`. Check a purchase/server read before revoking the old key in Apple. If creation succeeded but upload failed, check CherrySub status and the new key ID before rerunning: the first upload may have committed, and a private key may not be downloadable again.

Disconnecting stops the app's server credential use without deleting historical transactions or access evidence. Reconnect with the correct app identity and credential. [Troubleshooting](/docs/troubleshooting).

## Import the Apple product catalog

Open **Products → Import from store → App Store**. Product listing requires an App Store Connect API key from **Users and Access → Integrations → App Store Connect API**. Upload its `.p8`, Issuer ID, and Key ID in this screen. It is stored encrypted separately from the In-App Purchase key used by server history operations.

Save the key, load the store products, select subscriptions or one-time products, and preview the additions. Saving checks the key format; loading checks actual provider access and the bundle/numeric app identity. Existing products are kept. Access mapping is optional, and imported products do not create purchase evidence. Use **Change key** to replace catalog credentials. Disconnecting Apple removes both its managed connection and catalog key. [Migration guide](/docs/migration).
