## TL;DR
Correct the key identifier the lane passes so it matches an existing, active key in App Store Connect, and make sure the paired key file and issuer belong to that same key. Key id not found means the API looked up the identifier and found nothing: a typo, a key from another teams account, a revoked key, or CI injecting an old secret after rotation. Re-copy the three values as a set from the portal and update the CI secret together.

```text
key id not found - fastlane app_store_connect_api_key in CI
```

## Use this when
- app_store_connect_api_key fails in CI with key id not found.
- Keys were rotated and only some CI values were updated.
- The same Fastfile works on a developer machine with a local key file.

## Not for this skill when
- The key exists but calls return 401. That is the authentication mismatch case, not a missing key id.
- The issuer id is wrong while the key id is right. The API error can look similar; verify both values against the portal.

## Steps
1. Open App Store Connect, Users and Access, Integrations, and list the active key ids for your team. Verify: the active key ids are visible in the portal
2. Print, in the CI log or lane debug output, the key id the job actually used, masking nothing since ids are not secret. Verify: the used key id is captured exactly
3. Compare the used id with the portal list character by character, watching for swapped characters or an id from a different Apple team. Verify: the discrepancy, if any, is identified
4. Update the CI secret set together: key id, issuer id and key file from the same portal key, never mixing generations. Verify: all three CI values come from one key record
5. Confirm the key has not been revoked and its role covers the lanes actions. Verify: the key shows active with a sufficient role
6. Re-run the lane with a read-only API call first. Verify: the call succeeds and returns app data before any upload is attempted
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

## Why it happens
The key id is the lookup handle for the whole credential. CI secret sprawl makes stale handles common: a job keeps last years id while the key file was rotated, or a value is copied from a different teams portal. Because ids look like random strings, typos are invisible to eyeballing; only a character-level comparison against the portal settles it.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

## Variants and edge cases
### app_store_connect_api_key key id not found CI
CI phrasing; compare the injected id against the portal. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.
### fastlane api key not found after rotation
Rotation phrasing; update id, issuer and file as one set. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.
### Edge case: multiple teams
An Apple ID belonging to several teams can see several key lists. Confirm you are viewing the team the app belongs to. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kSaMt8mpFoCWESWzaMSV7g