Pulled from Google Trends on 20 August 2026, twelve-month worldwide window: around the seed "app store connect", the fastest-rising related queries are operational rather than conceptual. "app store connect support" (+250%), "apple developer" (+150%), "testflight" (+140%), "app store connect api" (+130%) and "app store connect api key" (+100%).
People are not asking what App Store Connect is. They are trying to make it do something automatically, and getting stuck on the credential.
Everything below is from Apple's own API documentation, fetched for this post. One note if you go checking: developer.apple.com/documentation/* pages are JavaScript shells that return a title and nothing else to a plain fetch — request https://developer.apple.com/tutorials/data/documentation/<path>.json instead and you get the real content.
What the key is
Apple's description is exact:
"An API key has two parts: a public portion that Apple keeps, and a private key that you download."
There are two kinds, and choosing wrong is the first place people lose an afternoon:
| Team key | Individual key | |
|---|---|---|
| Scope | "Access to all apps, with varying levels of access based on selected roles" | "Access and roles of the associated user" |
| Provisioning endpoints | Yes | No |
notarytool | Yes | No |
| Who can create it | An Admin account in App Store Connect | The user, from their own profile |
Team keys are created under Users and Access → Integrations → App Store Connect API → Team Keys. Apple is explicit that "Team API keys can access all apps, regardless of their role", so the role you assign is the only thing narrowing what that key can do. Admin-role keys "can do things like create new users and delete users".
The part that catches everyone
"The private key is available for download a single time."
Once. Not once per session, not re-downloadable from the key list. If you lose the .p8, the recovery path is to revoke the key and generate a new one, which means updating every place the old one was installed.
Apple's own security instruction is short and worth taking literally: "Secure your private keys as you do for other credentials, such as usernames and passwords. If you suspect a private key is compromised, immediately revoke the key in App Store Connect."
The token, field by field
Every request carries a JSON Web Token you sign yourself. Apple specifies both halves.
Header
| Field | Value | Note |
|---|---|---|
alg | ES256 | "All JWTs for App Store Connect API must be signed with ES256 encryption" |
kid | your key ID | e.g. 2X9R4HXF34, from the Integrations tab |
typ | JWT |
Payload
| Field | Value | Note |
|---|---|---|
iss | your issuer ID | a UUID, shown near the top of the API Keys page |
iat | issued-at, UNIX epoch | |
exp | expiry, UNIX epoch | "Tokens that expire more than 20 minutes into the future are not valid", except for a small set of listed resources |
aud | appstoreconnect-v1 | |
scope | e.g. GET /v1/apps/123 | optional; narrows what the token may do |
The twenty-minute rule is the one that turns into a support thread. A token minted with a one-hour expiry is not a long-lived token — it is an invalid one, rejected immediately, and the error does not always say why. If you are writing a client, mint short and mint often.
ES256 is also not negotiable, and it is not RS256. It is ECDSA over P-256 with SHA-256, which is why the key Apple hands you is an EC private key in a .p8 file rather than an RSA pair.
Holding a key that can act on your account
Worth saying plainly, because it changes how you should store this: a .p8 is not an API key in the read-only sense people are used to. Depending on its role it can create and delete users, and an Apple Ads key can spend a budget.
Appstro connects to Apple Ads with exactly this kind of credential, and the arrangement is deliberate enough to be worth copying:
- The private key never reaches the browser, in any form — not once, not to be echoed back into a form field.
- It is encrypted at rest with AES-256-GCM under a separate secret, inside a server function that is the only thing holding the decryption key.
- Its table has row-level security enabled with no policies at all, plus a blanket revoke, so every access has to go through that function's service role rather than through any client.
- The caller's identity is taken from a verified session token, never from the request body — a user id sent by the client is a claim, not an identity.
- Upstream failures are surfaced as generic messages, because Apple's error bodies can echo the signed assertion back at you and an error log is a place secrets go to be forgotten.
None of that is exotic. It is what you do with a credential that can spend money.
This is not the Apple Ads API
A distinction that costs people time: the App Store Connect API and the Apple Ads Campaign Management API are separate services with separate credentials, separate portals and separate token flows. Apple states that "App Store Connect API keys are unique to the App Store Connect API and you can't use them for other Apple services."
A key generated in App Store Connect will not authenticate an Apple Ads call, and the reverse is equally true.
What this cannot tell you
- Not what your key is allowed to do. That comes from the role assigned at creation, and it is visible in App Store Connect, not from anything public.
- Not whether a token failed because of
expor because of scope. Apple's errors are not always specific; check the simple things first, in the order this post lists them. - Not the rate limits. Apple documents them separately and they change; read the current page rather than a blog's copy of it.
- Nothing about anyone else's account. Everything reachable with this credential is yours.
The work
If you are wiring up automation, mint the token short, keep the .p8 off every client, and give the key the narrowest role that does the job. Appstro's connected Apple Ads account is the same shape on the Ads side, and its MCP server exposes the public App Store data that needs no credential at all — which is most of what people reach for the API to get.