App Store Connect API keys: individual vs team

An individual App Store Connect API key uses its user's roles and app access. A team key has a role you choose when you create it, but applies across the team's apps. For an integration that needs access to selected apps, start by reviewing a dedicated user's permissions and whether an individual key supports the required endpoints.

The choice comes up early when connecting an iOS release tool. You have a .p8 file, a Key ID, and a form asking which kind of key you created. Picking the wrong type can break authentication. Picking a key with broader access than the task needs gives the integration more reach than you intended.

Individual vs team API keys at a glance

Question	Individual key	Team key
Whose permissions does it use?	The associated user's roles and app access	The role assigned to the key
Can access be limited to selected apps?	Through an eligible user's app access	No; team keys apply across the team's apps
Where is it created?	The user's profile	The Team Keys section in Users and Access
Is an Issuer ID required for the JWT?	No; the payload uses sub: "user"	Yes; the payload uses iss
Which private file does the integration need?	The matching .p8 file	The matching .p8 file

Apple documents the two key types and their different JWT payloads. The comparison is about access boundaries. Either key can permit writes when its role allows them.

Start with the apps and actions the integration needs

Write down the required action before opening the key-generation screen. “List these two apps” is a useful requirement. “Connect Apple” leaves too much unspecified.

For example, imagine a team with a customer app and an internal test app. A release dashboard only needs to discover the customer app. A dedicated user with access to that app can provide a narrower connection than a team key. This is a hypothetical setup; the role and available endpoints still need checking against Apple's permissions.

App restrictions have conditions. Apple allows selected-app access for eligible users, including those with the Developer or App Manager role. Admin and Finance users cannot have their app access limited. Access to reports or Certificates, Identifiers & Profiles can also remove that restriction. Check the user's full access settings before relying on an individual key to isolate one app. Apple's app-access rules explain those conditions.

Then check the operation itself. Individual keys cannot use Provisioning endpoints, Sales and Finance, or notaryTool. A workflow that requires one of those needs a different credential choice. Follow the endpoint requirements in Apple's key documentation; do not change the key type simply because a connection form offers both options.

Create the key with the right account

Your Account Holder must first request App Store Connect API access if it is not enabled. Apple reviews that request. Team keys can be generated by an Account Holder or Admin. Individual key generation is available to eligible App Store Connect users unless that permission has been removed. Each user can have one active individual key. These prerequisites come from Apple's API access guide.

For an individual key, sign in as the user whose access the integration should inherit. Open your username, choose Edit Profile, and find Individual API Key. Generate the key there. Record the Key ID and store the downloaded private file securely.

For a team key, an authorized account operator opens Users and Access, then Integrations and Team Keys. Choose the role the integration requires when generating the key. Record its Key ID and Issuer ID alongside the private file. The operator's ability to create a key does not mean the new key needs an Admin role.

The private key download is available once. Plan where the file will be stored before creating it. Keep it in a controlled secret store or credential-management system, with a named owner who can replace it if the connection breaks. See Apple's private-key storage instructions.

Why the Issuer ID field changes

The .p8 file signs a JSON Web Token, or JWT. The client sends that signed token with an API request. The file itself is not the bearer token.

Both key types use a header containing the Key ID and the ES256 algorithm. Their payloads identify the caller differently:

• A team-key payload contains iss, set to the team's Issuer ID.
• An individual-key payload contains sub, set to the literal value user, and omits iss.

The audience is appstoreconnect-v1. A client can also include a scope claim to limit the token to particular requests. That is an additional request boundary; it does not turn a broadly privileged private key into a permanently restricted credential. These fields are defined in Apple's token-generation reference.

If you maintain the client, choose the payload from the actual key type. If you use an integration's setup form, confirm the type there rather than entering an Issuer ID copied from a different key.

Check a failed connection in a useful order

Keep the response details from the integration, but leave credentials out of screenshots and support messages. Then work through the input that can be checked without increasing access:

1. Confirm where the key was generated: a user's profile or Team Keys.
2. Match the Key ID to the .p8 file you uploaded. A file from another key will not sign as the Key ID you supplied.
3. For a team key, verify the Issuer ID. For an individual key, verify that the client uses the individual payload.
4. Check whether the key is still active.
5. Review the requested endpoint and the account's app access.

If authentication succeeds but an app is missing, compare the app list with what the associated user can access. A successful token does not prove that the account can see the app you intended to connect.

Avoid using an Admin key as a troubleshooting shortcut. Start with the exact missing operation or permission. Otherwise, the connection may start working while leaving you with a credential that can do much more than the original task.

Keep a replacement plan with the credential

Record the key type, Key ID, responsible account operator, and which integration uses it. Record the Issuer ID for a team key. Store the private file separately from those notes, and keep it out of source control, browser code, and chat.

If a private key is exposed, revoke it and replace the credential in the affected integration. Apple cannot reinstate a revoked key. Its revocation guide describes how account operators and individual users remove their keys.

For a planned replacement, test the connection with the new credential before treating the work as complete. Check the actual app list and bundle ID, then run the integration's normal read operation. A saved form is weaker evidence than a successful request against the intended app.

Connecting an App Store Connect key to Specita

Specita accepts individual and team keys. The connection form asks for the Key ID and .p8 file, plus the Issuer ID for a team key. The current integration discovers accessible apps and lets you map an iOS app to a Specita product. Check the bundle ID when making that mapping.

Specita currently uses an endpoint-scoped token to read the app list. App discovery and mapping do not imply that build, TestFlight, App Review, or rollout state has been synchronized. Those observations are not available in the current integration.

Use the App Store Connect setup guide for the exact Specita flow. After connecting, the post-deployment checklist explains how to keep delivery results and release-health evidence separate.