docs(TSP-1236): explain dual Slack auth methods across Builder and SuperGTM#622
docs(TSP-1236): explain dual Slack auth methods across Builder and SuperGTM#622claude[bot] wants to merge 1 commit into
Conversation
…perGTM Adds a new section and FAQ entry to the Builder Slack integration page clarifying the workspace-level bot token (Builder) vs per-user OAuth (SuperGTM) distinction. Updates the SuperGTM integrations page Slack accordion with the same context and cross-links between pages. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
🎯 Vibe checkReviewed: 2 files (1 with multiple issues, 1 relatively clean) Scores
Score key: 🟢 9–10, 🟡 6–8, 🔴 1–5. ✨ Overall vibe: The core addition — explaining that Builder and SuperGTM use different Slack auth methods — is genuinely useful and well-written on both pages. 🔧 Issues (11)
🧩 Component suggestions (2)
🏗️ Page structure (1)
✅ Clean files (1)
🔋 Credit usage
Files read: |
Summary
integrations/popular-integrations/slack.mdx, placed between the initial setup steps and the triggers section. Uses a two-card layout and an<Info>callout to clearly distinguish the workspace-level bot token (Builder) from the per-user OAuth token (SuperGTM).get-started/chat/super-gtm/integrations.mdxto note that SuperGTM uses per-user OAuth, with a cross-link to the Builder Slack docs and a note that workspace admins can allow one type while blocking the other.Motivation
Customers were confused when Slack worked in one area of the platform but not another, because the two connection types (workspace bot vs. per-user OAuth) can be allowed/blocked independently by workspace admins.
Test plan
/integrations/popular-integrations/slackand/get-started/chat/super-gtm/integrations<Info>callout renders correctly (single paragraph, no nested lists)<CardGroup cols={2}>layout renders correctlyLinear: https://linear.app/relevance/issue/TSP-1236/