Symptom: fastlane authentication fails after an App Store Connect API key was revoked.
Fastest fix: create a new key, replace every reference to the old credentials, then verify the API operation and upload separately.
This guide is for independent developers and small teams using fastlane to upload apps or manage TestFlight. It is especially useful when the release job runs on a remote Mac and the credential’s storage or configuration source is unclear.
First identify the failing layer
An API authorization error does not prove that Apple revoked the key. A token can be malformed or expired; a private key may not match the configured key ID; the account role may lack permission; or the job may be reading an outdated secret. Treat these as separate failure paths before rotating credentials.
Apple’s App Store Connect API overview explains the API’s authorization model. The token-generation requirements specify that a JWT can have a maximum lifetime of 20 minutes. That limit applies to the token, not to the underlying API key. A short-lived token problem is not, by itself, evidence that the key has been revoked.
| Failure signal or condition | Likely layer | First check |
|---|---|---|
| A request starts working after the lane generates a fresh JWT | Token generation or token lifetime | Confirm the lane creates a new token and uses the expected signing parameters. |
| Apple rejects a token even though it was just generated | Key material or token construction | Compare the configured key ID with the private key used to sign the JWT. |
| A previously working key consistently receives an authorization failure after revocation | Key status | Confirm the key’s status in App Store Connect; do not treat retries as recovery. |
| Authentication succeeds, but a specific operation is denied | Account role or API permission | Check the role assigned to the key and whether it permits that operation. |
| A local test works but a CI or remote Mac job fails | Configuration source or execution context | Inspect the secret store, environment, working directory, and file path used by that job. |
The diagnostic should follow the failed request to its actual source. A developer may have updated a local .env file while a scheduled runner still reads a CI secret, or changed the key file while the lane continues to pass the old key ID. Those are configuration mismatches, not proof that the replacement key is defective.
Revocation means replacement, not reactivation
Apple’s key-management documentation does not provide a reactivation path for a revoked API key. A revoked key cannot be enabled again, and the associated private key cannot be retrieved by downloading the same key a second time. The recovery action is to create a new key and update the systems that use it. Apple describes key creation and management in its App Store Connect API key documentation.
First confirm the status in App Store Connect rather than inferring it from a fastlane message. Then establish the scope of the change: identify every lane, CI workflow, scheduled task, and remote Mac job that might still reference the old key. If a key may have been exposed, revoke it promptly; keeping a possibly compromised credential active merely to avoid a short migration adds risk.
The private key file is not interchangeable with the key ID. A valid replacement requires the new key’s matching private key and identifier. Depending on the key type and configuration, the issuer ID may also be needed. Apple’s documentation explains the key-management boundary; fastlane’s App Store Connect API configuration guide explains how fastlane uses API credentials.
A fresh key does not repair stale configuration automatically. If one runner still reads the revoked key ID or an old p8 file, that runner can continue to fail even after another environment has been fixed.
Key type changes the migration plan
Personal API keys and team API keys have different ownership and management boundaries. Apple documents that an individual user can have only one active individual API key, while a team can create multiple team keys. This difference matters during rotation: a team may be able to create a replacement and migrate consumers before removing the old key; an individual key cannot be assumed to support the same overlapping migration.
| Key type | Management boundary | Rotation implication |
|---|---|---|
| Individual API key | Associated with an individual App Store Connect user and that user’s access | Check the user’s key status and permissions. Do not plan on creating a parallel individual key for a seamless overlap. |
| Team API key | Managed within the team’s App Store Connect account | A team can use separate keys for different workflows where appropriate, allowing a staged migration when account permissions permit. |
| Either type after revocation | The revoked credential cannot be re-enabled | Create a replacement and update each consumer; verify its access before relying on it for a release. |
Before creating a replacement, confirm that the account role can perform the required key-management action and that the replacement will have the access needed by the release task. A key that authenticates successfully may still lack the role permissions required to perform a particular operation. Conversely, changing the role without checking the release task can grant more access than the workflow needs.
This is a recovery decision, not a reason to redesign the team’s entire key strategy during an incident. Restore the minimum required release path first. After release operations are stable, the team can review whether separate credentials for distinct workflows would make later rotation easier to manage.
Replacement milestones on the remote Mac
The recovery should move through explicit milestones so that a credential change does not become an untraceable series of edits.
Milestone: inventory the old references
Record the revoked key ID as a reference for locating stale settings, but do not copy or expose its private key. Search the release configuration, secret-store entries, CI variables, scripts, and remote Mac job definitions for the old identifier and for the locations from which credentials are loaded.
Include workflows that are not run by the main release lane. A separate TestFlight job, a manual upload lane, or a scheduled metadata task may load credentials independently. If the team cannot establish which secret source a job reads, pause that job until its configuration is understood rather than assuming it shares the main lane’s settings.
Milestone: create the replacement under the right account
Use the appropriate App Store Connect account and key type. Record the new key ID and, where applicable, the issuer ID in the team’s approved secret-management record. Download and store the private key securely when it is created; do not assume Apple will let the team retrieve that same private key later.
The fastlane app_store_connect_api_key action reference lists the configuration fields used by the action, including the key ID and private-key input. Use the supported input method already adopted by the workflow, such as a protected file path or securely supplied content. Do not paste private-key material into a ticket, chat, source file, or command that may be retained in shell history.
Milestone: replace the credential source
On the remote Mac, update the secret store or protected file that the actual release job reads. Check permissions on the file and make sure the fastlane lane points to the replacement rather than to a similarly named but stale file. If a job uses environment variables, verify them in that job’s execution context; an interactive terminal and a background runner may not inherit the same environment.
Keep the private key out of version control, client-side code, build artifacts, and logs. Avoid printing environment variables during debugging. If a diagnostic needs to show which credential was selected, show a non-secret identifier such as the key ID, not the private-key contents.
For the remote host’s access and data-handling procedures, consult the ArmVNC data privacy information. That page does not replace the developer’s own secret-management policy; it helps teams review the hosting side separately from their application and CI configuration.
Milestone: update every consumer
Replace the old key ID and private-key source in each workflow that used the revoked credential. Check lane-specific configuration, repository or organization secrets, scheduled automation, and any manual release scripts. Update the issuer ID when the replacement setup requires it, but do not copy a value from an unrelated environment merely because it was present in the old configuration.
If a team key is being rotated as planned and both keys can remain active during migration, update and verify consumers in controlled groups before removing the old key. For an individual key, follow the account’s actual creation constraints and plan the change around the fact that a parallel active individual key may not be available. If revocation was triggered by suspected exposure, containment takes priority over uninterrupted deployment: revoke first, then restore the release workflow with a replacement.
Milestone: verify the configuration actually loaded
Check the effective configuration at the point where fastlane runs. Confirm that the intended key ID is selected and that the private-key file or secret belongs to that key. Confirm that the working directory, environment, and file path are the same in the test job and the release job.
The following checklist is designed for the handoff from credential replacement to release validation:
- [ ] Confirm the old key is revoked in App Store Connect.
- [ ] Confirm the new key belongs to the intended individual or team account.
- [ ] Match the new key ID to the private key supplied to fastlane.
- [ ] Confirm the issuer ID is set when the selected key configuration requires it.
- [ ] Replace old references in CI secrets, remote Mac jobs, lanes, and scheduled tasks.
- [ ] Confirm the release process does not print or store private-key contents in logs or source control.
- [ ] Run a permitted, low-risk API operation before starting the project’s upload lane.
- [ ] Confirm the upload result and the later App Store Connect processing state separately.
Independent FAQ
Can a revoked key be re-enabled?
No. Revocation is not a temporary lock that the team can clear. The old key must be replaced, and its previous private key cannot be recovered by downloading it again. If there is reason to suspect exposure, revoke it immediately and then update the consumers that still depend on it.
What does an invalid API key error in fastlane mean?
It can indicate a revoked key, but it can also point to a bad JWT, mismatched key ID and private key, incorrect issuer ID, insufficient account access, or stale configuration. Check the key status and the credentials actually loaded by the failing process before rotating again.
What needs updating after a key change?
Update all credential consumers, not just the visible lane: CI secrets, remote Mac jobs, scheduled workflows, scripts, and any separate upload or TestFlight task. Keep the key ID and private key paired, and verify issuer settings and permissions for the operation being tested.
How can a p8 file be changed safely on a remote Mac?
Deliver the replacement through an approved protected secret path, keep it outside source control, and configure the exact fastlane job to read it. Verify the job’s environment and working directory without printing the secret. Then perform a low-risk authorized operation before testing a full upload.
Separate authorization from delivery success
A successful API authorization test proves that fastlane can authenticate for that operation; it does not prove that a complete app upload has finished or that App Store Connect has completed subsequent processing. Treat these as separate checkpoints.
First, use an operation that is permitted by the new key’s role and is low risk for the release workflow. If it fails, return to the key status, token, permission, and configuration checks. If it succeeds, run the project’s actual upload task in the intended environment and review its output. Then inspect the resulting delivery state in App Store Connect instead of treating an authentication success message as a completed release.
When an upload fails after authentication, preserve the distinction between an API credential problem and a delivery or processing problem. Check which phase reported the failure, what operation fastlane attempted, and whether the same job used the expected key. This keeps teams from repeatedly rotating valid credentials to address a separate issue in the release pipeline.
Return to a stable release environment
A revoked-key incident often exposes a broader weakness: credentials may be duplicated across jobs, hidden in interactive shell settings, or tied to a Mac that is not reliably available when a release is needed. A local Mac gives the owner direct control and can be the right choice for sustained work or tasks that require physical interfaces. But relying on an already full development machine can mix personal development state with production release secrets, while buying and maintaining a dedicated Mac adds hardware and upkeep costs.
For occasional releases or a small team that needs a persistent macOS execution environment, renting a remote Mac can avoid purchasing a dedicated machine and gives the team a place to maintain its release workflow. It does not remove the need for secure key storage, least-privilege access, or credential rotation; it makes those controls easier to separate from a developer’s everyday workstation. Teams evaluating that option can review ArmVNC remote Mac access and the ArmVNC help center before deciding whether a hosted environment fits their release cadence.
The actionable recovery remains the same: once revoked, the old App Store Connect API key cannot be restored. Replace it, update every fastlane and remote Mac reference, and verify authorization, upload, and processing as distinct stages.
Frequently asked questions
Can a revoked App Store Connect API key be enabled again?
No. Apple’s key-management guidance treats revocation as permanent: the old key cannot be re-enabled, and its private key cannot be downloaded again. The recovery path is to create a replacement key, update every service that still references the revoked key, and verify the required App Store Connect operation. If compromise is suspected, revoke first rather than keeping a risky key active during migration.
What should be checked when fastlane says an API key is invalid?
First identify which key ID and private-key file the failing lane actually reads. Then distinguish a rejected or expired JWT from a revoked key, a mismatched key ID and p8 file, an incorrect issuer ID where one is required, and an account role that lacks permission. Check the failure response and the effective configuration before creating another key; authentication errors do not all mean revocation.
Which automation settings need changing after replacing an API key?
Update every reference to the old key, not only the fastlane configuration visible in the main repository. Check CI secret stores, remote Mac environment variables, lane-specific configuration, scheduled jobs, deployment scripts, and any separate TestFlight or upload workflow. Replace the key ID and private-key content or file together, and update the issuer ID when the new key type and account setup require it.
How should a p8 key be replaced on a remote Mac?
Transfer the new private key through the remote Mac’s approved secret-management or secure file-delivery path, then set the lane to read that exact file or secret. Keep it outside the repository and logs, restrict access to the release process, and confirm the working directory and environment used by the actual job. Test a low-risk permitted API operation before starting a production upload.
Test Your Replacement Key on ArmVNC
Run your release builds on a dedicated physical Mac with native macOS.