# How to Connect Slack to Your Bolt.new App > [!question] Lingering Questions > - How does the Bolt function actually verify Slack's request signatures using the signing secret — is that generated code trustworthy by default, or does it need a manual security check? > - Does the "outbound is cheap, inbound is expensive" auth pattern hold for other chat platforms (Discord, Teams), or is it Slack-specific? > [!tip] Article Ideas > - A reusable "send-to-Slack + react in real time" integration checklist, generalized past this one Bolt tutorial to any vibe-coded app that needs a chat-approval loop. > [!link] Cross Reference > - [[AI & the Future of Knowledge Work MOC]] — the human-does-config/agent-writes-code division of labor is a recurring pattern in this run's other agent-tooling sources. > - [[Product & Startup Instincts MOC]] — the outbound/inbound complexity split is a general integration-design instinct, not Slack-specific. > [!quote] Vocabulary > - **Incoming Webhook** — a one-way, no-auth-scope URL Slack issues per channel; posting to it pushes a message, no OAuth required. > - **Events API** — Slack's inbound mechanism; requires a subscribed bot token, a verified request URL, and app reinstall on scope change. ## Bib capsule Bolt.new (YouTube tutorial), "How to Connect Slack to Your Bolt.new App," https://www.youtube.com/watch?v=enzZ4J_876Q. ## Author's thesis (Adler Q1+Q2) The video argues that Slack apps turn a vibe-coded Bolt project into a two-way surface: push events out via incoming webhooks, react to them with interactive buttons or threaded replies, and reflect the result back into the app in real time — replacing an email round-trip for approvals and customer feedback. In detail, it walks through building two Slack apps end-to-end (webhook creation, signing secret, Interactivity request URL, bot OAuth scope, channel ID, Events API subscription) with the Bolt AI agent generating the app-side integration code while the human only handles Slack-dashboard configuration and secret-pasting. ## Key arguments 1. Outbound (webhook) integration and inbound (Events API) integration are structurally different in cost: outbound needs only a webhook URL; inbound needs OAuth scope, a bot token, a verified endpoint, and a reinstall on scope change. 2. Plan mode — having the agent ask clarifying questions before building — surfaces the app's architecture and catches ambiguity (e.g., an under-specified request-URL endpoint) before code ships. 3. The recipe generalizes: any Bolt-built feature can grow a "share to Slack" approval or feedback loop using the same webhook → secret → interactivity → events sequence. ## Claim atoms ### Incoming webhooks push app events into a Slack channel > [!quote] ID:rw_pending > "go to the incoming web hooks and toggle this on... add new web hook... this has created a new web hook URL. So let's copy this." **Context & use**: ~[00:01:41]–[00:02:46], the outbound path for both apps built in the video — the webhook URL becomes a Bolt secret. This is the minimum primitive for a Bolt app to post into Slack. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### Two-way Slack replies require a bot token, channel ID, and Events API > [!quote] ID:rw_pending > "under oorthth and permissions add the chat colon write scope and copy the bot user oorthth token." **Context & use**: ~[00:08:17]–[00:09:24], the `chat:write` scope + Bot User OAuth Token + channel ID + signing secret + `message.channels` event subscription enable threaded Slack replies to flow back into the app. Outbound is simpler than inbound; inbound needs full OAuth plus event subscription. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### Let the agent code the integration; the human does the dashboard config > [!quote] ID:rw_pending > "The agent's finished working and it's given us these instructions to now follow." **Context & use**: Throughout the video, the Bolt agent writes the integration code and emits step-by-step Slack config instructions; the human toggles dashboard settings and pastes secrets. Plan mode exposes the app's architecture before any code is written. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ## Permanent candidates - **Outbound chat integration is cheap; inbound is where the auth cost concentrates** — the strongest candidate here: it generalizes past Slack/Bolt to any platform that separates a no-auth push primitive (webhook) from an authenticated pull/react primitive (OAuth + events). Promoted below. ## Processing checklist - [x] Verbatim quotes carried over character-for-character from the existing deep-read notes - [x] Permanent candidate promoted — see linked note - [x] Connect into the relevant MOC — [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] - [ ] Verify the signing-secret verification step against Bolt's actual generated code, if this pattern gets reused ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — a concrete instance of an AI coding agent handling implementation while a human handles account-level configuration and trust decisions - [[3. Resources/Readwise/Articles/How to Connect Slack to Your Bolt.new App]] — source document