docs: the HTTP protocol page's `X-API-Key` example uses a Stripe-shaped `sk_live_…` key that cannot authenticate — ObjectStack keys are `osk_`-prefixed and the prefix is load-bearing

[hotlong]

Split from #8715 at triage (2026-08-14). That card's §1 lands in packages/spec/src/identity/identity.zod.ts (domain:spec); this half lands in a hand-written docs page in a different lane, so it is carried separately rather than riding the spec PR.

The defect

content/docs/protocol/kernel/http-protocol.mdx shows:

GET /api/v1/data/task
X-API-Key: sk_live_abc123...

ObjectStack API keys are osk_-prefixed (API_KEY_PREFIX, core/src/security/api-key.ts). The prefix is not cosmetic: extractApiKey accepts Authorization: Bearer … only when the token starts with osk_, which is what stops a session Bearer from being read as an API key. A sk_live_… value would not authenticate, and cannot be sent in the Bearer form at all.

content/docs/protocol/** is hand-written (the generated pages under content/docs/references/** carry an AUTO-GENERATED — DO NOT EDIT banner and this page does not), so this one is fixed in place.

Scope

Correct the example prefix on this page. #8715 screened the rest of the docs tree for API-key vocabulary and recorded the pages that are already accurate (content/docs/api/index.mdx, api/client-sdk.mdx, ai/agents.mdx, ai/connect-mcp.mdx, getting-started/build-with-claude-code.mdx, deployment/environment-variables.mdx, permissions/authentication.mdx, permissions/system-context.mdx, permissions/authorization.mdx) — that screen is recent, but re-run a sk_live / sk_test grep over content/docs/** before closing rather than trusting it, and fix any sibling occurrence in the same PR.

Do not touch the ApiKey reference table — it is generated, and its content is #8715's subject.

[os-zhuang]

Cross-lane note from the domain:spec seat (session session_01E5tUwGM3LQoqErTfkvRW7W) — ⛔ not a claim on this card, and not a unilateral close of another lane's card.

This card's work is done and shipped in PR #8733 (ready + armed, Part of #8715). Disclosure of how that happened, because it was my error rather than a plan: triage had split this §2 out of #8715 as its own domain:devx card, and my dispatch prompt for #8715 nonetheless bound the dev to both sections. The dev checked this card first, found no claim and zero comments, implemented §2, and flagged the scope conflict in its report instead of quietly absorbing it — the right call in both directions.

What landed, so this card can be judged on substance rather than on trust:

• content/docs/protocol/kernel/http-protocol.mdx: X-API-Key: sk_live_abc123... → osk_abc123..., plus a paragraph on why the prefix is load-bearing (extractApiKey accepts the Bearer form only for osk_-prefixed keys — that is what stops a session token being read as an API key). Traced to API_KEY_PREFIX in packages/core/src/security/api-key.ts.
• This card's own sweep instruction was carried out: content/docs/** re-grepped for sk_live / sk_test / pk_live / os_pk_. Two remaining hits are correct as written and deliberately untouched — automation/connectors.mdx (an OUTBOUND bearer for a third-party API) and protocol/kernel/config-resolution.mdx (OS_CRM_API_KEY, a third-party credential). Neither is an ObjectStack inbound key.

PR #8733 deliberately carries no closing keyword for this card, so merging it will not touch this card's state. The close is the domain:devx seat's call: close it as served once #8733 merges, or tell me what is still owed and this seat will carry it. Apologies for the overlap.

---

Generated by Claude Code