How to create an App Store Connect API key and use it in CI

Step 01 to 03: Generate the key and download it once

1. Sign in to App Store Connect as an Admin. Open Users and Access, then the Integrations tab, then App Store Connect API in the left column, and make sure Team Keys is selected.
2. Click Generate API Key (or the + button). The name is only a label for you. Under Access, pick the role. Team keys can touch every app on the team whatever the role, so the role is your only fence: pick the smallest one that covers what this key will do.
3. Click Download API Key next to the new key. You get AuthKey_<KEYID>.p8. Apple says the link "only appears if you haven't downloaded the private key" and that "Apple doesn't keep a copy." Save it somewhere that is not a git repo.

We are deliberately not showing a screenshot of our own Integrations page: it would publish our real key ID and issuer ID. They are not the secret, but there is no reason to hand them out.

Step 04: Sign a token and test it

Apple's token rules are short. Header: alg ES256, kid your key ID, typ JWT. Payload: iss your issuer ID, iat now, exp the expiry, aud appstoreconnect-v1, and an optional scope list. "For most requests, App Store Connect rejects a token with a lifetime greater than 20 minutes," where lifetime is exp minus iat.

This is the function from our Store/asc.py, which runs on Windows with the PyJWT and cryptography packages:

Test it with one read-only call:

curl -H "Authorization: Bearer $TOKEN" https://api.appstoreconnect.apple.com/v1/apps

A JSON list of your apps means the key, the IDs and the clock all agree. Paste a token into our JWT decoder to check the claims and the expiry before you blame Apple; it decodes in your browser and sends nothing anywhere.

Two notes from running this 139 times. First, our real script backdates iat by 60 seconds to absorb clock drift on runners; if you do that, shorten exp to match, because Apple measures the gap between the two. Second, Apple occasionally answers a valid token with a 401. Our call() helper retries a 401 up to twice with a freshly minted token, and those retries go through.

If you only need read access for a long-running dashboard, Apple accepts tokens of up to six months for some GET-only resources, but only when the token carries a scope that lists GET requests. Everything that writes stays under 20 minutes.

Step 05: Store the key as CI secrets

The .p8 is a text file, but a base64 string is easier to pass around as a single secret. From Git Bash on Windows, with the GitHub CLI:

base64 -w0 AuthKey_XXXXXXXXXX.p8 | gh secret set ASC_KEY_CONTENT
gh secret set ASC_KEY_ID
gh secret set ASC_ISSUER_ID

Piping straight into gh secret set means the base64 never lands in a file you could commit by accident. We do the same with the distribution certificate.

Step 06: Use it in fastlane and GitHub Actions

fastlane's app_store_connect_api_key action takes the three values straight from the environment. Set is_key_content_base64: true so it decodes the secret itself. After that, every fastlane action that talks to Apple (build numbers, upload, metadata, submit for review) uses the key, with no Apple ID anywhere.

Some tools want a file path instead of a string. Our workflow decodes the key into $RUNNER_TEMP, which sits outside the checkout and is wiped when the job ends, sets chmod 600, and logs only the byte count, never the contents.