Skip to main content

Slack app

Your agent in a Slack workspace, answering in the thread. Every event is verified before it becomes a run.

A Slack connection serves one agent, and answers with the version pinned on that agent's live Slack deployment. Mentions and direct messages arrive through Slack's Events API, the agent answers in the thread, and the conversation stays where the team already works. Slack support is part of the Community edition.

Connecting a workspace​

Rikoo is self-hosted, so there is no central Rikoo app to install: each company declares its own Slack app. Slack must be able to reach your instance at a public HTTPS address.

  1. Create a Slack app for your workspace, install it, and store its bot token (xoxb-…) and its signing secret on the Secrets screen.
  2. On the agent page, open the Deploy tab and click Manage the connection on the Slack card. Choose Manual token, select the two secrets and save.
  3. The dialog now shows the address to declare in Slack (Event Subscriptions, Request URL). It is unique to this connection. Set it in your app, together with the scopes and events of the app manifest the dialog provides (App manifest, ready to paste).
  4. Click Check the connection. The worker checks the token, and the status becomes connected, with the name of the workspace.
  5. Invite the bot to the channels where it should answer (/invite @your-bot). Slack delivers nothing from a channel the bot is not a member of.
  6. With the live environment selected, turn on the Slack switch of the Deploy tab.

The dialog only holds references to the vault secrets, and the API server never decrypts them. A bot speaks for one agent: a second agent needs a second Slack app.

Slack is served from live only

A workspace has no test environment of its own, so a test Slack deployment has no effect. What answers in Slack is always the version pinned on live, the one a publication gate has judged when gates are in use. Try a version in the Playground instead.

Who the bot answers​

The Slack deployment carries the bot's behavior. By default, the bot answers mentions in channels and direct messages, in every channel it has been invited to, and ignores other bots, since two bots answering each other would loop forever. Once the bot has answered in a thread, the thread continues without a new mention.

Verified on the way in​

Every request is verified

Slack signs each delivery. The public endpoint acknowledges at once and hands the raw body to the worker, which checks the signature and a five-minute timestamp window, then drops events it has already seen. A request that fails the check never becomes a run. The endpoint answers the same way whether the connection exists or not, so it tells a prober nothing.

A note on rate limiting​

The ingress endpoint is never limited by the calling address. At Slack, one address carries the traffic of thousands of customers: limiting it would cut off legitimate traffic, and Slack marks an endpoint that keeps answering 429 as failing. The limit is keyed on the connection being called, so a forged identifier only exhausts its own budget.

What the agent receives​

Text, and the files posted in the conversation. Files go through the same admission policy as the widget and the API, with the same types and size limits. A refused file is named to the agent, which tells the user. Everything from Slack is untrusted content and is framed as such: a message from a colleague is data, not instructions. Replies are text only, with no interactive buttons.