docs(TSP-1235): document Operator role API key permissions

[claude]

Summary

• Added a new Operator self-service API keys section to enterprise/org-project-level-api-keys.mdx explaining that Operators can create and manage their own personal Relevance API keys on enterprise plans
• Added a <Note> to the Relevance API key section of get-started/core-concepts/api-integration.mdx clarifying which roles can generate API keys, including the new Operator capability

Key messaging

• Operators can only manage API keys for their own account — not for other users or at the org/project-level integration layer
• Primary use case: self-service setup for connecting MCP clients (Claude Desktop, Cursor, VS Code, etc.)
• This is an enterprise feature enabled via a feature flag — users should contact their account representative to enable it

Related

• Linear: https://linear.app/relevance/issue/TSP-1235/
• API PR: RelevanceAI/relevance-api-node#14763

Test plan

• /enterprise/org-project-level-api-keys renders new "Operator self-service API keys" section correctly
• /get-started/core-concepts/api-integration shows the new <Note> callout under the Relevance API key section
• Anchor link #relevance-api-key in the cross-reference works
• No broken links introduced

🤖 Generated with Claude Code

[linear]

TSP-1235

[github-actions]

🎯 Vibe check

Reviewed: 2 files (1 with issues, 1 clean)

Scores

	Dimension	Score	What's holding it back
🟡	Consistency	8/10	Two heading sentence-case violations in org-project-level-api-keys.mdx (### Who Can Access Custom API Keys, ### Security Considerations).
🟡	Technical clarity	7/10	org-project-level-api-keys.mdx:27 claims project Editors can set project-level API keys — contradicts the RBAC permissions table, which shows only project Admins can "Manage project-level API keys & OAuths".
🟢	Non-technical clarity	9/10	Both pages define terms before using them and explain the "why" alongside the "how". Accessible without deep Relevance knowledge.
🟡	Structure	7/10	org-project-level-api-keys.mdx covers three distinct topics (org/project-level integration keys, Custom API Keys, Operator self-service) under a title that only advertises the first one — no unifying intro. FAQ accordion uses a bullet list, which CLAUDE.md prohibits.

Score key: 🟢 9–10, 🟡 6–8, 🔴 1–5.

✨ Overall vibe: api-integration.mdx is clean and well-scoped — good structure, clear distinctions, appropriate callouts. org-project-level-api-keys.mdx is the one to watch: it contains a permission claim (project Editors can set project-level API keys) that directly contradicts the RBAC reference page and could mislead enterprise admins setting up access controls.

🔧 Issues (2)

• enterprise/org-project-level-api-keys.mdx:47 — ### Who Can Access Custom API Keys → sentence case: ### Who can access custom API keys
• enterprise/org-project-level-api-keys.mdx:60 — ### Security Considerations → sentence case: ### Security considerations

🧩 Component suggestions (3)

• enterprise/org-project-level-api-keys.mdx:20–24 and 37–39 — both sets of numbered steps are sequential procedures; wrap in <Steps> for visual progress indicators. Also worth dropping the redundant "First," and "Then," openers — numbered steps already imply sequence.
• get-started/core-concepts/api-integration.mdx:31–35 — same: three sequential steps for adding a custom API key; <Steps> would be more consistent with how-to pages elsewhere.
• enterprise/org-project-level-api-keys.mdx:95–99 — the "What are the best practices for using Custom API Keys?" accordion uses a bullet list. CLAUDE.md requires accordion content to be flowing sentences. Rewrite as prose: "Limit the scope and permissions of Custom API Keys — prefer read-only or resource-scoped credentials. Isolate sensitive credentials in separate projects with restricted membership. Where possible, use OAuth via User Level Authentication instead of shared API keys."

🏗️ Page structure (1)

• enterprise/org-project-level-api-keys.mdx — the page title ("Organization- and project-level API keys") and opening paragraph describe only the first section, but the page also covers Custom API Keys and Operator self-service API keys as substantial standalone sections. A reader scanning the sidebar won't expect to find Custom API Keys documentation here. Add an intro paragraph that names all three topics the page covers, or consider whether Custom API Keys and Operator self-service deserve their own pages (they're already cross-linked from api-integration.mdx).

⚠️ Contradictions (1)

• enterprise/org-project-level-api-keys.mdx:27 states: "To set project-level API keys, you must have an Enterprise subscription and be an organization admin or owner, or project admin or editor." The RBAC permissions table at enterprise/rbac.mdx:106 shows "Manage project-level API keys & OAuths" is ✅ for project Admin only — Editor is ❌. One of these is wrong; the RBAC table is the authoritative reference so the Info callout on line 27 of the API keys page likely needs to drop "or editor".

✅ Clean files (1)

get-started/core-concepts/api-integration.mdx

🔋 Credit usage

Item	Count
Files reviewed	2
Context pages read	2
Total lines processed	~635

Files read: enterprise/org-project-level-api-keys.mdx (103 lines), get-started/core-concepts/api-integration.mdx (113 lines), enterprise/rbac.mdx (222 lines), enterprise/user-level-authentication.mdx (197 lines)