App Store Connect API Key: Team or Individual? 2026 Permission Checklist

The symptom: your upload job needs App Store Connect access, but nobody is sure whether a shared team key or a personal key is safer.

The fastest fix: use a restricted user with an Individual API Key when the workflow only needs a specific App; use a separate least-privilege Team API Key only when unattended automation needs Provisioning endpoints or another capability unavailable to the individual key.

This guide is for:

Independent developers who build and distribute through TestFlight.
Small teams managing multiple Apps and release responsibilities.
CI maintainers running fastlane, Transporter, or custom scripts on a persistent remote Mac.

Start with the permission boundary

An App Store Connect API Key is not a replacement for every Apple signing credential. It authenticates API requests, while certificates, identifiers, provisioning profiles, and the private signing key remain separate parts of the release chain. Treating these as one permission system is the first reason teams overgrant access.

Apple documents two relevant API key models:

An Individual API Key is associated with a specific App Store Connect user. Its effective access follows that user’s role and permitted App scope.
A Team API Key is created for the organization or team and receives permissions through an assigned App Store Connect role.

The key type affects more than authentication. It changes who owns the credential, how access follows a person’s account, how the credential is handed over, and how much of the team can be affected when you revoke it. Apple’s [official key creation documentation](https://developer.apple.com/documentation/appstoreconnectapi/creating-api-keys-for-app-store-connect-api) describes the creation eligibility, private-key download behavior, and differences between these key types.

Key takeaway: the narrowest identity that can complete the release task is usually the correct starting point.

Do not choose a Team API Key merely because a job runs without a human at the keyboard. “Unattended” describes the execution mode, not the required authorization level. First list the API calls, Apps, signing operations, and TestFlight actions involved. Then select the smallest identity that can perform all of them.

Use this decision branch before creating a key

Apply the following conditions in order.

If one developer controls one App and only needs build upload, TestFlight distribution, or metadata automation, choose a restricted user plus an Individual API Key. Confirm that the user’s role and App access cover the intended calls.
If the job must access Provisioning endpoints or another capability that the Individual API Key does not support, choose a dedicated Team API Key with the lowest suitable role. Do not upgrade it to Admin simply to make an authentication error disappear.
If several people need access to the same automation, do not pass around one person’s private key. Create a dedicated automation identity or a controlled team credential, document its owner, and define its revocation condition.
If the workflow must be isolated to one App, prefer a user identity whose App access can be restricted. A Team API Key can be assigned a role, but it cannot be limited to one individual App. Creating several Team API Keys does not create App-level isolation.
If an external developer only needs to upload TestFlight builds for a named App, create a separate user identity with the smallest App scope that works. Remove that user and revoke its key when the engagement ends.
If the required operation involves signing certificates or provisioning profiles, separate the API decision from the signing-material decision. An API Key may authorize an API request without granting or supplying the private key needed to sign an archive.

This branch avoids the common mistake of starting with the highest role and trying to reduce it later. A reduction is useful only after you know which call failed and why.

Set the minimum for an individual developer

For a solo developer, an Individual API Key is often the cleanest option when the task is limited to an App you already control. The credential inherits the user’s access model instead of becoming a broad shared object that survives independently of a person’s day-to-day account.

This is especially suitable for:

Uploading an archive or package through an approved tool.
Managing beta distribution in TestFlight.
Reading or updating release metadata within the user’s allowed scope.
Running a local script for one App or a small number of Apps that the same user is authorized to manage.

The important limitation is operational: every user can retain only one active individual key. That makes key replacement a planned change rather than a casual way to keep several versions in parallel. If you switch tools or move the workflow from a laptop to a remote Mac, record the old key’s use, install the replacement securely, run a controlled test, and remove the old reference.

Can an Individual API Key manage certificates and provisioning profiles?

Not automatically. The key’s user association and role do not mean that every Certificates, Identifiers & Profiles operation is available through the same credential. Apple separates App Store Connect API permissions from developer-account resources, and the exact support depends on the endpoint and the tool. Check Apple’s current endpoint documentation and the tool’s authentication implementation before designing the pipeline around a personal key.

If the workflow only uploads builds and distributes TestFlight releases, do not introduce certificate-management access without a concrete need. If it must create or retrieve provisioning profiles through an endpoint unavailable to the individual credential, that is the point at which a dedicated Team API Key deserves evaluation.

The credential still does not replace the signing asset itself. A successful API authentication request cannot sign an archive when the required certificate, provisioning profile, entitlements, or private signing key is absent from the build environment.

Separate responsibilities in a small team

A small team should divide access by function rather than assign Admin to the person who happens to own the release script. At minimum, distinguish these roles:

Release owner: approves production releases and handles account-level decisions.
Daily developer: builds and tests features, but may not need broad distribution or account-management access.
Automation identity: runs the repeatable upload or TestFlight job.
External collaborator: works within a defined App and a defined contract period.

Use Apple’s [role permissions reference](https://developer.apple.com/help/app-store-connect/reference/account-management/role-permissions) to map the required task to the least powerful role that supports it. The role should be selected from the operation, not from the team member’s seniority.

A Team API Key can be appropriate when the automation must operate independently of an individual employee or contractor. It is also easier to keep stable when a person leaves the project. That stability creates a larger blast radius, however: the key is not an App-level boundary. If its role reaches several Apps, a mistake in the script or a leaked private key can affect the entire scope available to that role.

Use separate credentials for materially different duties. A key used to upload a staging build should not automatically become the key used by a production release pipeline. This separation does not create App isolation by itself, but it limits which workflow must be stopped when a credential is compromised or retired.

Which key should fastlane use for automated uploads?

Choose an Individual API Key when fastlane runs for a restricted user and the required actions are supported by that user’s permissions. Choose a Team API Key when fastlane needs unattended access to Provisioning endpoints or another documented capability that the individual credential cannot provide. In both cases, configure the minimum App Store Connect role and test the complete command sequence, not only the token-generation step.

Apple’s build upload guidance should be treated as the upload boundary. It does not prove that the following TestFlight, metadata, signing, or release-management stages will also succeed. A command that returns an upload success message is not proof that the build is visible to testers or ready for distribution.

An outside developer should not receive a long-lived Team API Key merely because they need to upload a TestFlight build. Create an independent user identity where the required App scope and role can be constrained. The identity should be attributable to that person or contract, rather than hidden behind a shared account.

A contractor may touch four separate access layers:

The App Store Connect user identity.
The API Key and its private key.
The remote Mac login account.
The code-signing certificate, provisioning profile, and related private material.

These layers must be revoked separately. Removing a user does not necessarily clean a private key file from a build host. Disabling remote login does not revoke an API credential already copied into a script. Deleting a certificate does not remove the contractor’s App Store Connect access.

What should an external developer receive for TestFlight delivery?

Give the contractor only the App Store Connect user access and App scope required for the agreed upload task. Use a separate key for that identity, avoid shared team credentials, and define an end date for access. If the contractor needs the remote Mac, create a separate host account or access path, then remove the host credentials and clean stored signing material after the project closes.

Document the handover without copying the private key into a ticket, chat transcript, or project wiki. Record the credential owner, intended workflow, App scope, role, installation location, and revocation trigger. The record should help you find and disable the access without becoming another secret store.

Protect credentials on a remote Mac

A remote Mac changes the storage problem, but not the authorization model. The machine may remain online while you sleep, while a contractor is offline, or while multiple builds wait in a queue. That makes unattended credential exposure more consequential than a short local test.

How should you store an App Store Connect private key on a remote Mac?

Keep the private key outside the repository, outside build artifacts, and outside public or normally retained logs. Inject it only into the job that needs it, restrict filesystem access to the build account, and prevent shell tracing from printing the key or generated token. Store the Key ID and Issuer ID as configuration values, but treat the private key as secret material that requires stronger protection.

The JWT flow uses three concrete pieces of identity data: the Issuer ID, the Key ID, and the private key. Apple’s JWT generation documentation also defines the token claims and validity rules. The generated token should be short-lived; Apple documents a maximum expiration interval of 20 minutes for API request tokens. Do not place a long-lived JWT in a repository or reuse a token after its intended job.

A safe remote workflow should include these controls:

Create a dedicated operating-system user for the build process where possible.
Set restrictive permissions on the private-key file and its parent directory.
Pass secrets through the platform’s protected secret mechanism or a controlled runtime injection step.
Mask command output and disable verbose shell tracing around authentication commands.
Keep the private key out of git, cache archives, crash reports, and uploaded artifacts.
Limit who can log in to the host through VNC, SSH, or the web console.
Maintain a written recovery path for replacing the host without copying secrets into an image.

A remote Mac can be a sensible choice when you need a persistent macOS build environment without purchasing another local machine. Before selecting a host, review the [MACGPU remote Mac options](https://macgpu.com/en/index.html) against your required administrator access, credential injection method, online availability, and reset procedure. Those host controls complement App Store Connect permissions; they do not replace them.

Verify the full release path, not just authentication

A new credential is not accepted merely because it can generate a JWT. Validate the release path in layers so that an authorization problem is not confused with a signing or distribution problem.

Confirm account eligibility. Have the Account Holder or an authorized administrator verify that API access is enabled and that the intended key type can be created by the chosen person.
Write the task boundary. List the required operations: archive, signing, upload, metadata changes, beta-group management, or other release actions. Mark which operations are App Store Connect API calls and which require certificates or profiles.
Select the role. Compare the list with Apple’s official role-permission reference. Remove every permission that is not required by the job.
Create the key and capture identifiers safely. Store the Key ID and Issuer ID in the deployment configuration. Download the private key once through the documented process and move it into protected secret storage. Do not copy its contents into the runbook.
Test identity only. Run a harmless API request and verify that the token is accepted. This confirms authentication, not signing or upload readiness.
Test the archive. Build with the intended bundle identifier, certificate, entitlements, and provisioning profile. If this fails, changing the API role will not repair the signing environment.
Test a controlled upload. Use a non-production build or controlled App target where possible. Apple’s TestFlight overview explains the distribution stage that follows processing.
Verify visibility and permissions. Check that the build reaches the expected App, appears after processing, and is visible to the intended testers or release operators.
Inspect logs for leakage. Search job output for the private key, JWT contents, authorization headers, and unmasked environment variables. A passing release with exposed secrets is still a failed security test.
Rotate deliberately. Install the replacement credential, execute one real but controlled release, then revoke the old key and confirm that no scheduled job still references it.

When you revoke access, use Apple’s [API key revocation procedure](https://developer.apple.com/documentation/appstoreconnectapi/revoking-api-keys). Revocation should be paired with removal from the remote Mac, CI secret store, local shell configuration, and deployment cache. Otherwise, the account may be closed while a copied secret remains available elsewhere.

Score the choice by operating risk

Use this qualitative score before approval:

Individual API Key: strong fit for one developer, one or a few permitted Apps, and low-frequency automation where the supported endpoints are sufficient.
Individual API Key: weak fit when the workflow needs a capability the individual credential does not expose, or when the process must remain independent of a person’s account lifecycle.
Team API Key: strong fit for a dedicated unattended pipeline that needs documented team-level capabilities and has a clearly bounded role.
Team API Key: weak fit when the team wants App-level isolation, when several unrelated projects would share it, or when the only reason for Admin access is uncertainty about the required endpoint.
Shared credential: reject when the team cannot identify who owns it, where it is stored, which Apps it can reach, or how to revoke it.

For a solo developer, the default decision is usually an Individual API Key attached to a restricted user. For a small team, the decision depends on whether App isolation or endpoint coverage is more important. If App isolation wins, use separate restricted users and personal keys. If unattended capability wins and the endpoint requires it, use a dedicated Team API Key with the lowest role, while accepting that the team key cannot be scoped to a single App.

This approach also keeps your release process portable. If you later move fastlane from a laptop to a persistent remote Mac, you can transfer the workflow design without transferring a shared personal credential or broadening the role by guesswork. For guidance on moving signing material to a new build host, review the remote Mac environment options from MACGPU only after the identity and secret boundaries are documented.

Replace the current setup only when the conditions justify it

A local Mac with credentials scattered across shell profiles is easy to start and difficult to audit. A shared Team API Key may keep a pipeline running, but it can expose multiple Apps, hide ownership, and make contractor offboarding incomplete. A short-lived cloud runner can reduce host maintenance, yet may leave you rebuilding signing and secret injection logic for every job.

If your current setup has broad shared access, no App-level ownership, unclear private-key storage, or no tested revocation process, a persistent remote Mac can offer a more controllable release workstation—provided you configure separate host access, protected secret injection, and an environment recovery procedure. Renting through MACGPU is most defensible when you need temporary or recurring Mac build capacity and want to avoid buying a dedicated machine solely for CI. If you require stable heavy workloads for years, physical interfaces, or permanent local access, purchasing and managing your own Mac may be the better fit.

Choose the key first, then validate the host. A remote Mac is only part of the solution; the safer release chain is the one where App Store Connect identity, signing material, operating-system access, logs, and revocation can each be inspected and disabled independently.