How to Connect Slack to Your Bolt.new App  🔗 **Source:** [How to Connect Slack to Your Bolt.new App](https://www.youtube.com/watch?v=enzZ4J_876Q#transcript) > [!note]+ Document Notes > tags: [bolt-new, slack-integration, vibe-coding, webhooks, oauth, no-code-tools] > author: [MISSING] > source: Bolt.new (YouTube) > reference: https://www.youtube.com/watch?v=enzZ4J_876Q > date created: 2026-06-18 09:45 > > # 🏷️ Title: How to Connect Slack to Your Bolt.new App > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Bolt.new](https://bolt.new) - [Slack API — your apps dashboard](https://api.slack.com/apps) - [Slack Incoming Webhooks](https://api.slack.com/messaging/webhooks) - [Slack Interactivity & Shortcuts](https://api.slack.com/interactivity) - [Slack Events API](https://api.slack.com/apis/events-api) ## 📝 Summary - **What happened.** A Bolt tutorial walks through building *two* Slack apps and wiring them into a Bolt.new project (a "social post generator"). The first sends a social post into Slack with approve/deny buttons that write status back to the app; the second posts customer feedback into a Slack channel and pipes a threaded Slack reply back into a new in-app feedback page. - **Why it matters.** It's a concrete, end-to-end recipe for connecting an AI-vibe-coded web app to Slack using Slack's standard primitives — incoming webhooks, interactivity, OAuth bot tokens, and the Events API — narrated at the click level. The differentiator is letting the Bolt agent generate the integration code while the human only does the Slack-dashboard config and secret-pasting. - **Key stakeholders.** Bolt.new users / vibe-coders, no-code/low-code builders, teams that already live in Slack and want lightweight approval or feedback loops, and Slack workspace admins who control app installation. - **Risks and tradeoffs.** Secrets (webhook URL, signing secret, bot token) are pasted into Bolt's secret store and depend on the agent wiring them correctly; the agent sometimes builds without real-time updates and must be re-prompted; request-URL endpoints can be under-specified so the human must ask the agent to clarify; permission-scope changes force an app reinstall. - **Bottom line.** Slack apps turn a Bolt project into a two-way surface: push events out via webhooks, react with interactive buttons or threaded replies, and reflect the result back into the app in real time — saving the email round-trip for approvals and feedback. ## 📖 Main Content - **The goal pattern.** Take an existing Bolt app feature (here, a social post generator that researches a topic and drafts a post) and add a "share to Slack" path so a stakeholder — a social media manager — can approve or deny the post from inside Slack rather than the app. - **Plan mode first.** Each build starts by clearing context (new feature) and writing a plain-English prompt, then putting the Bolt agent in *plan mode* so it asks clarifying questions (one fixed channel? what fields to include? a link back?) before building. The narrator frames plan mode as a way to *see the agent's thinking* and understand app architecture before code is written. - **App 1 — buttons (outbound + interactive).** Create a Slack app "from scratch" in the Slack dashboard; name it and pick a workspace. The agent then issues step-by-step instructions: (1) enable **Incoming Webhooks**, add a new webhook to a chosen channel, copy the webhook URL into a Bolt secret; (2) copy the **Signing Secret** from Basic Information into a second secret; (3) toggle **Interactivity & Shortcuts** on and set the **Request URL** to a Bolt database functions endpoint (`/functions/v1/slack-interactions`), assembled from the project's env-file database URL plus the function path. Testing shows the "share to Slack" button posting the research report + generated copy to the channel with approve/deny buttons; clicking writes the status back to the app instantly via real-time. - **App 2 — threaded replies (two-way text).** A second app handles customer feedback: a sidebar widget opens a modal for email + feedback, which posts into a "direct customer feedback" Slack channel via another incoming webhook. The second half makes Slack replies flow back: the agent requires a **bot token** (add the `chat:write` scope under OAuth & Permissions, copy the **Bot User OAuth Token**), the **channel ID**, the **signing secret**, and **Event Subscriptions** (verify the request URL, subscribe to the `message.channels` bot event). The bot must be invited to the channel (`/invite`), and changed scopes force an app **reinstall**. A threaded reply in Slack then appears on a new in-app "feedback" page. - **Real-time caveat.** Status and replies update without a page refresh because the app uses real time; if the agent omits it, the fix is to prompt "please use real time." - **Endpoint ambiguity caveat.** For Event Subscriptions, the agent's request-URL instruction was "not specific enough"; the human asks the agent (in plan mode) for the *full function endpoint* and pastes the verified URL. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=enzZ4J_876Q&t=0) Why connect Slack, and what we'll build - Slack is framed as the "unanimous tool for communicating with stakeholders" because it's simple. - Goal: bring Slack's simplicity to interact with website features in real time via Slack apps. - Two apps will be built and connected to Bolt projects, on top of a social post generator. #### ⏱️ [00:00:34](https://www.youtube.com/watch?v=enzZ4J_876Q&t=34) The approval use case - User researches a career question, summarizes a social post, copies text to post elsewhere. - Imagined need: sign-off from a social media manager before posting — approve/deny directly in Slack. #### ⏱️ [00:01:07](https://www.youtube.com/watch?v=enzZ4J_876Q&t=67) Prompt + plan mode + creating the Slack app - Prompt: add a "share to Slack" button next to copy that sends post text + platform into Slack. - Sent in plan mode; clarifying answers: one fixed channel; include platform label, research title, and text; add approve/deny buttons that pass tags back to the social postcard. - In Slack dashboard → manage apps → create app from scratch → name "social post feedback" → choose workspace. #### ⏱️ [00:01:41](https://www.youtube.com/watch?v=enzZ4J_876Q&t=101) Incoming webhooks + secrets - Agent's step 2: enable Incoming Webhooks, add new webhook, select workspace + new "social posts" channel, allow. - Copy webhook URL → Bolt secrets → paste as Slack webhook URL secret. - Copy signing secret from Basic Information → save as a Bolt secret. #### ⏱️ [00:03:19](https://www.youtube.com/watch?v=enzZ4J_876Q&t=199) Interactivity + request URL - Toggle Interactivity & Shortcuts on. - Set request URL to the Bolt database functions endpoint; get the database URL from the env file, append the function path (`slack-interactions`), save. #### ⏱️ [00:03:54](https://www.youtube.com/watch?v=enzZ4J_876Q&t=234) Testing approve/deny - "Share to Slack" button posts "new post for review" with the research report and generated copy. - Manager clicks approve → app shows approved; second post → deny → app shows denied, instantly, no refresh (real time). #### ⏱️ [00:05:00](https://www.youtube.com/watch?v=enzZ4J_876Q&t=300) Real-time note + second app intro - If the agent builds without real time, prompt "please use real time." - Next: instead of buttons, reply via a Slack thread and see the text appear in the app — for customer feedback (replacing the email loop). #### ⏱️ [00:05:32](https://www.youtube.com/watch?v=enzZ4J_876Q&t=332) Customer feedback widget app - Prompt: new Slack app responding to customer feedback; sidebar widget opens a modal for email + feedback; submitting posts into a "customer feedback" Slack channel. - Create app "customer feedback," new "direct customer feedback" channel, enable incoming webhook, copy webhook into a Bolt feedback secret, test — feedback appears in Slack. #### ⏱️ [00:07:11](https://www.youtube.com/watch?v=enzZ4J_876Q&t=431) Two-way replies: bot token, channel ID, events - Prompt: respond in Slack and pass the response to a user via a new "feedback" sidebar page. - Agent steps: add `chat:write` scope under OAuth & Permissions, copy Bot User OAuth Token → secret; get channel ID (click channel name, scroll to bottom) → secret; signing secret → secret. #### ⏱️ [00:08:50](https://www.youtube.com/watch?v=enzZ4J_876Q&t=530) Event subscriptions + endpoint clarification - Enable events; request URL "not specific enough" — ask the agent for the full function endpoint, paste, see "verified." - Subscribe to bot event `message.channels`; save. - Invite the bot to the channel via `/invite`; reinstall the app because scopes changed. #### ⏱️ [00:09:58](https://www.youtube.com/watch?v=enzZ4J_876Q&t=598) Final test + recap - Submit feedback ([email protected], "less errors") → new feedback page appears; Slack shows "reply in this thread to send your response back." - Threaded reply "Agent V3 will be ready next week" appears in the app. - Recap: two Slack apps — buttons and threaded text feedback — save time over email. ## 📚 References - [Bolt.new](https://bolt.new) — the AI app builder used in the tutorial - [Slack API: your apps](https://api.slack.com/apps) — where apps are created from scratch - [Incoming Webhooks for Slack](https://api.slack.com/messaging/webhooks) — outbound message posting - [Interactivity & Shortcuts](https://api.slack.com/interactivity/handling) — buttons and request URL handling - [Events API](https://api.slack.com/apis/events-api) — `message.channels` subscription - [OAuth scopes (`chat:write`)](https://api.slack.com/scopes/chat:write) — bot token permission to post ## 🗣️ Paraphrase - Slack is the default stakeholder-communication tool, so it's useful to drive your website's features through it in real time; this video builds two Slack apps connected to Bolt projects, layered on a social post generator. - For the first app, the builder prompts the Bolt agent to add a "share to Slack" button, uses plan mode to answer clarifying questions, then creates a Slack app from scratch. - The agent's instructions are: enable incoming webhooks and copy the webhook URL, copy the signing secret, and turn on interactivity with a request URL built from the project's database URL plus a function path — all saved as Bolt secrets. - Testing shows the post arriving in Slack with approve/deny buttons that write status back to the app instantly through real time; if the agent skips real time, you re-prompt for it. - The second app posts customer feedback from a modal into a Slack channel, then enables threaded replies back into the app using a bot token (`chat:write`), the channel ID, the signing secret, and an Events API subscription to `message.channels`. - Loose ends matter: the bot must be invited to the channel, scope changes force a reinstall, and an under-specified request URL is resolved by asking the agent for the full function endpoint. - The payoff is a two-way Slack ↔ app loop for approvals and feedback that's faster than email. ## 📰 Newsletter **Wire Slack into your vibe-coded app — without leaving the chat** Living in Slack already? This Bolt.new tutorial shows how to make your AI-built app *talk back* to Slack in real time — twice. App one adds a "share to Slack" button that drops a drafted social post into a channel with **approve/deny** buttons; one click writes the verdict straight back into the app, no refresh. App two flips the direction: a customer-feedback widget posts into Slack, and a **threaded reply** lands on a fresh in-app page — goodbye email round-trip. The clever part is the division of labor: the Bolt agent writes the integration code while you do the Slack-dashboard config — enable an **incoming webhook**, grab the **signing secret**, toggle **interactivity**, then for two-way text add a **bot token** with `chat:write`, the **channel ID**, and an **Events API** subscription to `message.channels`. A few real gotchas to bookmark: if updates don't appear live, prompt "please use real time"; if the request URL looks vague, ask the agent for the *full function endpoint*; remember to `/invite` the bot to the channel; and any scope change means **reinstall the app**. It's a tidy blueprint for lightweight approval and feedback loops that meet your team where they already are. ## ✅ Action Items #### DevRel - Developer advocacy: turn the two-app pattern (buttons vs. threaded replies) into a short demo for vibe-coding audiences. - Education: a workshop on Slack app primitives — webhooks, interactivity, Events API, OAuth scopes — for no-code builders. - Developer experience: publish a copy-paste checklist of secrets (webhook URL, signing secret, bot token, channel ID) and the request-URL pattern. - Developer marketing: clip the "approve/deny from Slack" moment as a feature highlight. - Community management: collect common failure modes (missing real time, unverified request URL) into a troubleshooting thread. - Internal/external/cross-project: Not applicable to this source. #### OSPO - Policy & Governance: Not applicable to this source. - License Compliance: Not applicable to this source. - Security Management: note that webhook URLs, signing secrets, and bot tokens are sensitive — document secret-rotation guidance. - Software Inventory: Not applicable to this source. - Developer Support: Not applicable to this source. - Community Engagement: Not applicable to this source. - Strategic Alignment: Not applicable to this source. #### Community - Maintainers: Not applicable to this source. - Contributors: Not applicable to this source. - Sponsors: Not applicable to this source. - Ecosystem: Not applicable to this source. #### WordPress - Core: Not applicable to this source. - Core Performance: Not applicable to this source. - Core AI: Not applicable to this source. - **Core Program Team:** Not applicable to this source. - Mobile: Not applicable to this source. - Playground: Not applicable to this source. - Community: Not applicable to this source. - Training: a tutorial mapping these Slack primitives to a WordPress plugin webhook/REST integration could mirror this flow. - Marketing: Not applicable to this source. - Support: Not applicable to this source. - Design: Not applicable to this source. - Documentation: examples-first guide for "send to Slack + react in real time" patterns. - Photos / TV / Openverse: Not applicable to this source. - Polyglots: glossary for "incoming webhook," "signing secret," "bot token," "Events API," "real time." - Accessibility: ensure any in-app Slack-status UI meets WCAG (see Accessibility Assessment). - Meta: Not applicable to this source. - CLI: Not applicable to this source. - Hosting: Not applicable to this source. - Tide / Themes / Plugins: Not applicable to this source. #### The WPCC - Programs: Not applicable to this source. - Projects: Not applicable to this source. - Funding experiments: Not applicable to this source. ### FAIR - Technical independence: Not applicable to this source. - Policies and covenants: Not applicable to this source. - Productized governance artifacts: Not applicable to this source. ## 🧪 Hypotheses - H1: Letting the agent generate integration code while the human does dashboard config reduces total setup time versus hand-coding the Slack integration. - H2: Using plan mode before building reduces rework (fewer re-prompts) on integration tasks. - H3: Slack-based approval loops shorten approval cycle time compared to email-based sign-off. - H4: Threaded-reply feedback channels increase response rates versus email feedback because replies happen where the team already works. - H5: The "please use real time" re-prompt is a recurring failure pattern that could be eliminated by a default project setting. ### 📊 Methodology - H1/H2: timed build trials comparing agent-assisted vs. manual integration, and plan-mode vs. no-plan-mode, counting re-prompts and errors. - H3/H4: A/B comparison of Slack approval/feedback loops vs. email loops, measuring cycle time and response rate. - H5: instrument Bolt builds to log how often real time is omitted and how often the re-prompt is needed. ### ❓ Questions - How are the Slack secrets stored and scoped in Bolt, and what's the rotation story? - What exactly is the database functions endpoint (`/functions/v1/...`), and does it imply Supabase under the hood? - How does the app verify Slack request signatures using the signing secret? - What happens to in-flight approvals if the webhook URL or bot token is revoked? ### 🔮 Future Research - A hardened reference implementation with signature verification, retry handling, and secret rotation. - Patterns for multi-channel or per-user routing instead of one fixed channel. - Error-handling UX when Slack delivery fails (timeouts, rate limits). - Generalizing the pattern to other chat platforms (Teams, Discord) from the same agent prompts. ### 💡 Implications - **Practice:** Two-way Slack integration becomes accessible to non-engineers by splitting code (agent) from config (human). - **Policy:** Handling Slack tokens/secrets in a low-code tool raises secret-management and least-privilege expectations. - **Security:** Signing-secret verification and `chat:write`-only scopes are the guardrails; reinstall-on-scope-change is a real operational step. - **Education:** Slack's primitives (webhooks, interactivity, Events API, OAuth) are the reusable mental model worth teaching. - **Funding models:** Not applicable to this source. ### 🧠 Learning Styles Assessment - Reading level estimate: spoken tutorial transcript; ~Flesch–Kincaid Grade 7–9 (short imperative sentences, but dense product/Slack jargon). Flesch Reading Ease ~60–70. #### 👀 Visual learners - Present: strong — it's a screen-share walkthrough showing each Slack dashboard toggle and Bolt secret being pasted. - Improve: an architecture diagram of app ↔ webhook ↔ Slack ↔ Events API; a before/after of the post card state; labeled screenshots in a companion doc. #### 🔊 Aural learners - Present: continuous narration explaining each click. - Improve: a 2–3 minute audio recap of the two app patterns and the gotchas. #### 🗣️ Verbal learners - Present: plain-language naming of each step and Slack feature. - Improve: a glossary callout (incoming webhook, signing secret, bot token, Events API, real time). #### 🧩 Kinesthetic learners - Present: strong — it's a do-along, step-by-step build the viewer can replicate. - Improve: a downloadable checklist and a starter Bolt project to fork. #### 🧠 Logical learners - Present: clear ordered procedure (create app → webhook → secret → interactivity → test). - Improve: a decision table for "buttons vs. threaded replies" and a flowchart of the request-URL assembly. #### 🧑‍🤝‍🧑 Social learners - Present: none — solo screencast. - Improve: a community thread for sharing integration variants and troubleshooting. #### 🧘‍♀️ Solitary learners - Present: strong — self-paced follow-along format. - Improve: a self-check ("did approve/deny write back? did the thread reply appear?") and reflection prompts. #### 🌿 Naturalistic learners - Present: none. - Improve: frame the feedback loop as an ecosystem (signal in Slack → action in app) analogy. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: YouTube provides a structured player; the app's new feedback page should use proper headings. - Improve: ensure the share-to-Slack button and approve/deny status have accessible names and live-region announcements. #### Keyboard navigation - Present: standard web controls in the app and Slack. - Improve: verify the modal (email + feedback) traps focus correctly and is fully keyboard-operable. #### Contrast and readability - Present: depends on the Bolt-generated UI theme. - Improve: verify 4.5:1 on the "awaiting review/approved/denied" status tags. #### Text resizing and reflow - Present: responsive web app assumed. - Improve: confirm the sidebar widget and modal reflow at 200% zoom without clipping. #### Media and captions - Present: YouTube auto-captions likely available. - Improve: add human-reviewed captions and a written step-by-step transcript for the procedure. #### Forms and interactions - Present: the feedback modal has email + feedback fields. - Improve: explicit labels, inline validation for the email field, and accessible toast/status updates when feedback is sent. #### Standards reference - Maps to WCAG 2.2 AA: 1.2.2 (captions), 1.4.3 Contrast, 2.1.1 Keyboard, 2.4.3 Focus Order, 3.3.1/3.3.2 Labels & error handling, 4.1.3 Status Messages (the real-time status updates). ### 🌍 DEIB Assessment #### Cultural breadth - Present: neutral, tool-focused content with no region-specific assumptions. - Improve: note that Slack adoption varies; offer parallels for teams on other chat platforms. #### Inclusive language - Present: plain, role-neutral ("social media manager," "customer"). - Improve: define Slack/Bolt jargon inline for newcomers (signing secret, bot token, Events API). #### Neurodiversity support - Present: consistent step ordering and repeated structure across both apps. - Improve: chunked summaries and an at-a-glance checklist to reduce working-memory load over a ~10-minute procedure. #### Representation - Present: single unnamed narrator; example data is generic ([email protected]). - Improve: vary example personas and scenarios beyond a single approval/feedback use case. #### Psychological safety - Present: encouraging, low-pressure tone; normalizes re-prompting the agent when it gets something wrong. - Improve: explicitly reassure beginners about handling secrets safely (don't share webhook URLs/tokens). ### ✅ Logical Validity #### Strong reasoning - Causal (procedural): each step plausibly produces the stated result — enable webhook → copy URL → secret → message posts; the cause→effect chain is demonstrated live, not asserted. - Analogical: "Slack as the stakeholder-communication surface" motivates replacing the email approval/feedback loop; the analogy is apt and concrete. - Inductive (generalization): the two worked examples support the broader claim that Bolt apps can be two-way Slack surfaces, though only two cases are shown. #### Fallacies - **Hasty generalization (mild)** — "Slack has become the unanimous tool for communicating with stakeholders." Quote location ~[00:00:00]. Overstated as universal. Fix: qualify as "widely used," or cite adoption data. - **Appeal to ease (mild)** — the smooth screencast implies the integration is frictionless, while the transcript itself reveals friction (missing real time, vague request URL). Fix: foreground the gotchas as expected steps rather than asides. #### Tone of voice - Friendly, instructional, enthusiastic ("Let's dive in," "And just like that"); confident and reassuring, occasionally promotional toward Bolt and Slack. ### 🛡️ DARVO Analysis - Not applicable to this source. This is a neutral procedural tutorial with no accuser, accusation, or defensive reframing. Deny/Attack/Reverse-victim-offender dynamics do not appear; the only "denial" is the literal Slack "deny" button for rejecting a post, which is product functionality, not rhetoric. ## 🎯 Conclusion - **Bottom line.** Connecting Slack to a Bolt.new app follows one repeatable pattern in two flavors: push events out with an **incoming webhook**, react interactively (approve/deny **buttons** or a **threaded reply** via the Events API + a `chat:write` bot token), and reflect the result back into the app in **real time**. The human handles Slack-dashboard config and secret-pasting; the Bolt agent writes the code. - **Next steps for readers.** (1) Start in plan mode so the agent surfaces clarifying questions before building. (2) Collect your secrets up front — webhook URL, signing secret, and (for two-way text) bot token + channel ID. (3) If updates don't appear live, prompt "please use real time"; if a request URL looks vague, ask the agent for the full function endpoint. (4) Remember to `/invite` the bot and reinstall the app after any scope change. ## 🔄 Refactor Appendix — How to Connect Slack to Your Bolt.new App > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults applied. Resonance filter on. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] 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 — webhook URL becomes a Bolt secret. - This is the minimum primitive to post from a Bolt app into Slack. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H2] 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]: `chat:write` scope + Bot User OAuth Token + channel ID + signing secret + `message.channels` event subscription enable threaded replies back into the app. - Outbound (webhook) is simpler than inbound (events); inbound needs OAuth + event subscription. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H3] 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 Bolt agent writes integration code and emits step-by-step Slack config instructions; the human toggles settings and pastes secrets. - Plan mode surfaces clarifying questions and exposes app architecture before the build. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Outbound chat integration is cheap; inbound is where the auth cost lives **Claim** (one sentence, Courtney's voice): Posting from an app into a chat tool needs only a webhook URL, but receiving and acting on replies requires full OAuth scoping, event subscriptions, and an app reinstall, so the integration's real complexity is concentrated on the inbound path. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds for Slack-style platforms separating incoming webhooks from the Events API + bot tokens. Breaks where a platform unifies send/receive behind one credential, or where only outbound notifications are needed. **Links**: - [[Webhooks vs polling]] — because extends - [[OAuth scopes and least privilege]] — because applies-in the inbound auth path - [[Vibe coding division of labor]] — because contrasts on who writes code vs. config <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Build a reusable "send-to-Slack + react in real time" reference for one real Bolt project — https://www.youtube.com/watch?v=enzZ4J_876Q #fleeting #inbox - [F2] Open question: how does the Bolt function verify Slack request signatures with the signing secret? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a checklist of Slack secrets (webhook URL, signing secret, bot token, channel ID) for chat integrations — #things - [ ] Note the "please use real time" + "ask for full function endpoint" gotchas in the integrations resource — #things <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/How to Connect Slack to Your Bolt.new App.md|How to Connect Slack to Your Bolt.new App by Bolt.new]] ## Highlights - familiar with when building out a Slack app. You'll see the settings and the features with the ability to share to the Slack marketplace if you choose. For this, we'll just build an internal app, so we won't worry about that. The agent's finished working and it's given us these instructions to now follow. Step one, create a new Slack app, which we've just done. Now, step two, go to the incoming web hooks and toggle this on. So, under features, let's scroll down to incoming web hooks. Let's activate incoming web hooks. And here is where we click add new web hook. Make ([View Highlight](https://read.readwise.io/read/01kvdbehe42ftn64qzbmxv8ygt)) - Note: H1 — the agent codes / human configures division of labor: it hands you steps; incoming webhooks are the outbound primitive both apps depend on. - Tags: integration, slack, atom/literature/h1 - builds it out. Plan mode is a great way to improve your understanding of the app architecture and what's going on behind the scenes. The plan looks good. We've answered the clarifying questions, turned it off plan mode, and let's build. The agent's finished building, and now it's asking us to do a few more steps within Slack. Step one, configuring the bot token. So under oorthth and permissions add the chat colon write scope and copy the bot user oorthth token. So here we are in oorthth and permissions down in bot scopes. Let's add that scope chat column. Right, ([View Highlight](https://read.readwise.io/read/01kvdbem33ped2cse0n68dj9qg)) - Note: H2 — two-way replies concentrate the auth complexity: bot token + chat:write scope + events (the costly inbound path vs. a simple outbound webhook). - Tags: atom/literature/h2