Slack is a dynamically resolved integration. Its operations are resolved from Slack’s OpenAPI specification at runtime, so agents do not import a Slack-specific package. Register the operations you need with
guildServiceTool("slack", ...) from the Guild Agents SDK.Feature overview
What your Guild Slack integration can do depends entirely on which agents you choose to connect. The integration is highly flexible. The exact capabilities depend on how you configure your Guild agents. Here are a few examples:Ask questions

File feature requests

Post rule-based alerts

Authentication
- Type: OAuth 2.02
- Token management: Slack tokens don’t expire — no refresh needed
Setup
1
Open Credentials
Go to Credentials in Guild.
2
Connect Slack
Click Slack and authorize Guild in your workspace.
3
Create a trigger
Go to triggers and create a new trigger.
4
Invite the agent
Invite the Slack agent to channels where you want
message events. app_mention works without an invite.OAuth scopes
Usage
Slack is dynamically resolved, so you do not import a Slack-specific package. Register the operations your agent needs withguildServiceTool() from the Guild Agents SDK, passing slack as the service name. Guild resolves each operation against Slack’s OpenAPI specification and injects credentials through the connected workspace account.
Name each tool with the slack_ prefix to match the underlying operation — for example, the chat_post_message operation becomes the slack_chat_post_message tool.
Selecting specific tools
Agents perform better with fewer tools. Register only the operations your agent needs — add each one as its ownguildServiceTool("slack", ...) entry:
API endpoints
Messages
Messages
Conversations
Conversations
Reactions
Reactions
Files
Files
Pins
Pins
Reminders
Reminders
Users
Users
User groups
User groups
Team
Team
Webhook events
Slack uses an agent-scoped webhook model — a single webhook receives all events and Guild routes them to matching triggers.
Events can be filtered to specific channels by setting
channel_ids in the service configuration. Messages from the Slack agent itself are automatically excluded to prevent feedback loops.
How the integration works
Guild uses Slack’s OAuth v2 flow. When you connect Slack, Guild receives a bot access token scoped to the installed workspace.- Long-lived token — Slack bot tokens do not expire. Guild stores the token once; no refresh flow is required.
- Bot only — Guild does not receive a user token. All API calls run as the bot, not as the installing user.
- One workspace per connection — Each Slack install maps to one
team_idand one bot token. - Bot user ID — Guild captures this at install time and uses it to filter out the agent’s own messages and prevent feedback loops.
Inbound events
Slack pushes events to a single agent webhook. Guild validates payloads with HMAC-SHA256 (X-Slack-Signature and X-Slack-Request-Timestamp), deduplicates by event_id, and routes events to matching triggers.
Use channel_ids in trigger service_config to limit which channels fire your agent. An empty channel_ids array matches all channels.
Outbound API calls
Agents call the Slack Web API through Guild’s proxy, which injects the bot token. The runtime exposes operations asslack_* tools (for example, slack_chat_post_message). Messages always appear from the bot — you cannot post as a specific user.
Guild scrubs URLs, thumbnails, avatars, and permalinks from webhook payloads before they reach agents to reduce token usage.
Session link tracing
When an agent posts a message to Slack viachat.postMessage, Guild automatically appends a link back to the originating workspace session — unless the message already contains a link to that session. This makes it easy to trace any Slack update back to the agent run that produced it.
The link is added as a short footer line. If you want to suppress it for a specific message, include the session URL in the message body yourself.
Session links support graded disclosure. When you click a Slack session link, you no longer hit a 404 if you are logged out or lack workspace access. Guild responds based on your authorization state:
- If you have access, Guild redirects you to the canonical workspace session URL.
- If you are logged in but lack access, Guild shows the name and type of the account that owns the session.
- If you are logged out, Guild confirms the session exists and prompts you to sign in.
Link and media unfurling
To keep Slack channels clean, Guild disables link and media unfurling by default on every message an agent posts viachat.postMessage. Unfurling generates automatic previews of links and media, which can clutter channels and add noise.
Guild sets unfurl_links and unfurl_media to false on outgoing message payloads. This applies to all posted messages, whether or not a session link tracing footer is appended.
An agent can override either default by passing unfurl_links: true or unfurl_media: true in the message payload. Guild respects the explicit value and does not disable that unfurling.
Limitations
- You must invite the Slack agent to channels to receive
messageevents (app_mentionworks without an invite) - If
channel_idsis empty in trigger config, events from all channels are processed - If someone uninstalls the Slack agent from the workspace, reconnect credentials in Guild. Guild does not receive a revocation webhook.
- Configure
SLACK_WEBHOOK_SIGNING_SECRETfor webhook verification