Slack setup without the maze

Most “chat to Slack” products still want you to live in their inbox. CanWeChat treats Slack as a first-class reply destination: one workspace, one channel, one active destination at a time. If your team already lives in a product channel, that can be enough.

This tutorial is for founders and small support pods who want website visitors to show up as Slack threads—without configuring a second helpdesk they will forget to check.

Quick answer

• Create a Slack app with bot scopes, install it to your workspace, and copy the bot token plus signing secret.
• Paste credentials into CanWeChat, set the Events URL, and choose one channel ID.
• Visitor messages open a thread; reply in that thread to send text back to the widget.
• Only one reply destination is active: choosing Slack pauses inbox/Discord/Telegram delivery for replies.
• Lock widget domains and install the script before you announce chat on the homepage.

What you will build

A visitor on your site opens the CanWeChat bubble (Shadow DOM widget). Their message is stored in D1, pushed over realtime sockets where needed, and queued to Slack so a third-party blip does not fail the visitor send. Your team answers in the Slack thread; CanWeChat verifies the inbound Slack signature and relays the reply to the widget.

Prerequisites

• A CanWeChat workspace on the 3-day trial or Pro ($19/month).
• Permission to create a Slack app in your workspace.
• Your public site key and widget installed with data-site.
• A channel your team actually watches (private channels need the bot invited).

Step-by-step Slack setup

1. In Slack API, create an app From scratch and pick your workspace.
2. Under OAuth & Permissions, add bot token scopes required for posting and reading thread replies (as listed in CanWeChat Slack docs—follow the current checklist there).
3. Install the app to the workspace and copy the Bot User OAuth Token.
4. In Basic Information, copy the Signing Secret.
5. In CanWeChat, open Integrations → Slack, paste the bot token and signing secret, and save before Slack URL verification.
6. Copy the Events Request URL from CanWeChat into Slack Event Subscriptions and verify.
7. Subscribe to the bot events CanWeChat lists (message events for thread replies).
8. Set the destination channel ID in CanWeChat and activate Slack as the reply destination.
9. Invite the bot to the channel if it is private.
10. Send a test message from the widget; confirm a new thread appears.

Finding the channel ID

In Slack, open the channel details and copy the channel ID (it typically starts with C). Paste that exact value into CanWeChat. Do not paste a channel name; names rename, IDs do not.

How replies work day to day

Each new visitor conversation maps to a Slack thread. Reply in-thread as the bot’s conversation partner using the format CanWeChat documents (plain team replies in the thread are the default path). Avoid starting a new top-level channel message for the same visitor—you will split context and the relay will not know which conversation to update.

• Visitor → widget → Workers → D1 → queue → Slack thread.
• Agent reply in thread → Slack signs request → CanWeChat verifies → widget updates via realtime.
• Optional: also send signed webhooks to your CRM with the same conversation IDs.

The one-destination rule

CanWeChat allows inbox, Slack, Discord, or Telegram—but only one is active for replies. That constraint is product design, not a missing checkbox. Split-brain reply (“I answered in Slack, someone else answered in inbox”) creates duplicate visitor messages and support embarrassment. Pick the place your team already opens every morning.

If you later move from Slack to Discord, switch the active destination in the dashboard and tell the team once. Historical threads remain in Slack; new visitor messages follow the new destination.

Security basics that come with Slack as destination

Bot tokens and signing secrets are encrypted at rest in CanWeChat. Inbound Slack requests are verified before any message write. Still treat the Slack channel as sensitive: visitor emails and page URLs will appear there. Prefer a dedicated #site-chat channel over posting into a company-wide watercooler.

Troubleshooting

• URL verification fails: re-save signing secret, confirm the Events URL is HTTPS, retry verify.
• Messages never appear: bot missing chat:write (or equivalent), or not invited to a private channel.
• Replies do not reach the widget: event subscriptions missing, or Slack is not the active reply destination.
• Wrong channel: channel ID typo; recreate the test after fixing.
• Duplicate noise: multiple CanWeChat workspaces pointing at the same Slack app—use one mapping.

Go-live checklist

1. Widget installed with data-site on production hostnames.
2. Allowed domains locked in Settings.
3. Slack active as the single reply destination.
4. Signing secret saved; Events URL verified.
5. Test visitor message → thread → reply → widget.
6. Team knows to reply in-thread only.

The CanWeChat angle

We encrypt integration secrets at rest, verify Slack’s signatures on the way in, and fan out through Cloudflare Queues so Slack latency is not on the visitor’s critical path. The product stays narrow on purpose: one site, one destination, $19/month after a 3-day trial—not a seat matrix for a helpdesk you did not ask for.

Limitations

• Not a full Slack support suite: no SLAs, no complex assignment rules, no multi-channel simultaneous reply.
• File-heavy workflows and deep ticket taxonomy belong in a helpdesk.
• You still need someone watching the channel—software cannot invent staffing.