App Store Connect API keys: scope, rotation, and what to do if one leaks

Posted by Kyle Hankinson May 1st, 2026

If you're using any third-party tool that reads your App Store sales data -- including Daily Sales Email -- it's almost certainly authenticating with an App Store Connect API key. Those keys are sensitive and most indie developers handle them more casually than they should. This is a practical guide on getting it right.

Pick the right scope

When you create an API key in App Store Connect (under Users and Access > Integrations), Apple makes you choose a role. The options include Admin, App Manager, Developer, Marketing, Customer Support, Account Holder, Finance, and Sales and Reports.

For analytics tools -- anything that just reads sales data -- you want Sales and Reports. It's the narrowest read-only role that includes the Sales and Trends API endpoints. It does not let the holder of the key:

Create or modify apps
Submit builds
Change pricing
Manage users
Read banking or tax info
Touch your account configuration

If a tool asks for App Manager or Admin access just to send you a report, push back. The only legitimate reason for that level of access is if the tool also writes to your account -- which an analytics tool shouldn't be doing.

Rotate keys periodically

Apple doesn't auto-rotate keys for you. The default is "valid until you revoke it." A reasonable cadence for keys used by external tools is every 12 months: at year-end or during a yearly maintenance day, generate a fresh key, paste it into your tools, then revoke the old one in App Store Connect.

If you've never rotated, no shame -- most indie devs haven't. Pick a date in the next 30 days, do it once, and put a calendar reminder for next year.

What to do if a key leaks

If you accidentally commit a .p8 file to a public GitHub repo, paste it into a chat, or otherwise expose it publicly:

Revoke the key in App Store Connect immediately. Users and Access > Integrations, select the key, hit Revoke. The leaked key becomes useless within minutes.
Generate a fresh key with the same Sales-and-Reports role.
Update every tool that was using the old key -- your local scripts, Daily Sales Email, any other analytics service. They'll start getting 401 Unauthorized from Apple until you swap the key in.
Don't just delete the leak from version history. If the leak is in a public Git repo, GitHub's caching and indexing means the secret may have already been scraped by attackers. Revoking is what protects you, not deleting; deleting just hides the evidence.
Audit your account afterwards (Sales > Trends, Payments and Financial Reports, the recent users list). A Sales-and-Reports key can't actually do anything destructive, so the impact of a leaked key in this role is limited to "someone now sees your sales numbers" -- annoying but not catastrophic.

How Daily Sales Email handles your key

The full details are on the Security page, but to summarize:

The .p8 private key is encrypted with AES-256-CBC before being written to our database, with a per-record initialization vector.
The plaintext key only exists in memory while a daily report is being fetched. It is not logged, not written to disk, and not transmitted anywhere except to Apple.
You can rotate the key at any time by pasting the new contents into your account page. The old encrypted key is overwritten on save.
If you delete your account, the encrypted key row is removed within five minutes -- no archival copy.

One specific recommendation

If you use multiple analytics tools (Daily Sales Email plus, say, AppFigures or RevenueCat), generate a separate key for each. There's no rate-limit cost -- Apple's API quotas are per-key but easily tolerated by analytics workloads -- and it means a leak in one vendor's pipeline doesn't expose your other vendors. It also makes "I'm done with vendor X, revoke their access" a single revocation rather than a coordinated rotation across everyone you've ever shared the key with.

Good hygiene that takes 30 seconds at sign-up time and saves you hours later.