[alukach]

Closes #594. Part of #588.

What

Service accounts and their API keys over /api/v1, documented at /api/docs:

Endpoint	Operation
GET /accounts/{owner}/service-accounts	listServiceAccounts → {items, next_cursor: null}
POST /accounts/{owner}/service-accounts	createServiceAccount — local_id, name, github_subjects[], grants[{product_id, role}], optional key{label, expires_at}; the response carries the issued key when one is asked for
GET /accounts/{sa}/trusts	listTrusts → {items, next_cursor: null}
POST /accounts/{sa}/trusts	addGithubTrust — {subject}
DELETE /accounts/{sa}/trusts?issuer=&subject=	removeTrust — 404 for a trust the account doesn't have; returns the trust as it was
GET /accounts/{sa}/keys	listKeys → {items, next_cursor: null}, revoked and expired keys included, never a hash
POST /accounts/{sa}/keys	issueKey — {label, expires_at} → 201 with key, the only time it appears
PATCH /accounts/{sa}/keys/{key_id}	updateKey — {expires_at?, revoked?: true}

src/lib/operations/service-accounts.ts holds the rules the issue names: GITHUB_ACTIONS_SUBJECT_REGEX (as a Zod schema shared with the OpenAPI doc), the read/write-only grant roles, managedServiceAccount (every "not yours / missing / not a service account" answers 404, keeping the single answer it gave before), and the rule that a service account can't own another. The server actions in src/lib/actions/service-accounts.ts now adapt FormData into those operations, and the service-accounts settings page lists through listServiceAccounts. Editing and deleting a service account are main's PATCH and DELETE /accounts/{account_id} (#674, #675): rename and disable call updateAccount, and delete calls deleteAccount, so this PR adds no operation of its own for them. Trusts are returned through AccountTrustSchema, so the table's identity sort key stays out of responses.

setProductAccess now calls inviteMember / updateMembership / revokeMembership, and creation grants each product through inviteMember too, so every grant passes the same authorization, duplicate check and audit log; so product access over the API is the product members endpoints from #589 with role read_data or write_data, and gets no endpoint of its own.

API keys were first left to #570 and #580–#582, which built the keys and their settings UI but no API; with those merged, this PR adds the API for them (scope noted on #594). issueApiKey, revokeApiKey, setApiKeyExpiry and the create action now map form fields onto issueKey, updateKey and createServiceAccount, so no action touches the keys table, and the key rules (hash-only storage, the six-character hint, refusing a disabled account, the expiry range) are tested once, on the operations.

Worth a look

• Revoking is PATCH {"revoked": true}, not DELETE: the record stays, with revoked_at, revoked_via and revoked_by, as disabling an account is a PATCH. revoked: false is refused with 400, since a revoked key can't be restored; revoking one twice is 409, and a PATCH with neither field is 400.
• expires_at is an ISO time, at most 3650 days away, or null for a key that lasts until revoked. It is required on issue, so a caller chooses no-expiry deliberately. The settings form still takes days and converts them.
• A key requested with POST /service-accounts is validated with the rest of the body, before anything is written, and stored after the grants and trusts.
• createServiceAccount checks every grant against InviteMembership before it writes the account, so a grant the caller may not make leaves nothing behind and a retry with the same local_id succeeds. inviteMember can refuse nothing else afterwards: the account is new and enabled, and the grants are deduplicated first.
• Deleting a service account is main's deleteAccount on both the API and the settings page. It deletes the account's API keys rather than revoking them, and the key exchange also refuses a key older than its account, so a key from a deleted account can't sign in as the next account to take its id. ADR 013 still holds.
• setProductAccess refuses a new grant to a disabled service account (fix(service-accounts): refuse new product access while disabled #666) through inviteMember and updateMembership, which both check serviceAccountGrantProblem. Revoking still works while the account is disabled.
• Service-account lists use the {items, next_cursor} page shape, as products and data connections do, so pagination can arrive later without a breaking change.

Docs, ADRs, llms.txt

• docs.source.coop docs/using-source/upload/with-service-account.md walks through the settings UI, which is unchanged, so it still holds; it could later mention issuing a key over the API, which API: publish the generated reference and retire api.docs.source.coop #595's reference covers meanwhile. The API reference is API: publish the generated reference and retire api.docs.source.coop #595's to publish.
• data.source.coop ADRs: I checked 005 (authorization), 010 (account-owned roles) and 013 (API keys). ADR 013 has source.coop generate the key, store only its hash, show it once, refuse a disabled service account and keep expiry editable, with key_id as the public handle; the key endpoints do exactly that, so this PR implements existing decisions and moves none.
• public/llms.txt: no change. These endpoints all need auth, so they can't go on the file's no-auth URL list, and its existing "API reference" line points at /api/openapi, which now includes them.

Storybook

No component changed. The settings page now gets its list from the operation, and the key actions keep their form fields and state shapes, so IssueApiKeyDialog and the rest are untouched.

Testing

• npm run type-check: clean.
• npx jest: 96 suites, 1068 tests pass. That includes the service-account action tests, now run through the operations; the key action tests, now checking only the form mapping; new operation tests (list authz, JSON create, the 404 on an unknown trust, a refused grant or bad key writing nothing, issuing, listing, expiring and revoking keys); and the OpenAPI validity and route-coverage tests.
• Not exercised against a running server.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
source-coop-ui	Ready	Preview	Oct 17, 2026 4:14am UTC
source-cooperative	Ready	Preview	Oct 17, 2026 4:14am UTC

[claude]

Claude finished @alukach's task in 16s —— View job

---

✅ No blocking issues — safe to merge.

I read src/lib/operations/service-accounts.ts in full. I did not read the route files, the action rewrites or the tests, and I did not run anything. For the operations file:

• Authorization: every operation goes through managed() or canManageAccountServiceAccounts, and 404s don't reveal whether an account exists.
• Create ordering: createServiceAccount checks the owner, then each grant, before it writes the account. A refused grant therefore leaves nothing behind.
• Key storage: keys are stored by hash, the plaintext is returned only on issue, and publicKey strips hashes from lists.
• Disabled accounts: both issueKey and addGithubTrust refuse a disabled account.

Non-blocking observations:

• createServiceAccount is not atomic after the account row is written. If a later inviteMember, trust create or key store throws, the account stays, and a retry with the same local_id gets 409. The grants are pre-checked, so this only happens on infrastructure errors. Say so in the docs, or delete the account on failure.
• updateKey can set expires_at on a key that is already revoked or expired. That makes an expired key valid again, which is intended per the PR text ("extended"). A revoked key stays refused regardless, since the revocation check is separate.
• updateKey still allows extending a key on a disabled account. That is fine as long as the exchange refuses disabled accounts, which ADR 013 says it does.

Docs

The PR description names docs.source.coop with-service-account.md (still holds), ADRs 005, 010 and 013 (implements existing decisions), and llms.txt (no change, with a reason). That satisfies the requirement, so there is nothing to flag.

Simplify (ponytail)

• service-accounts.ts publicTrust and the managed wrapper are each used in several places. Keep both; no cut.
• updateKey builds the returned record by hand with spreads (...(revoked && {...})). Re-fetching the key, or having set/revoke return the updated record, would remove the duplicated field logic and any drift from what was stored.
• Page, onePage and pageSchema for next_cursor: null add a speculative pagination shape. It is deliberate and matches products, so I'd keep it.

---

💰 Estimated review cost: $0.14 · 0m15s · 4 turns