Mattermost with DevFlow: setup, scope and limits

DevFlow connects to your Mattermost server as a bot and listens in allowlisted channels. A teammate mentions the bot, gets a read-only answer about the repository and can turn the thread into a task whose plan is approved by reply. Setup is 4 steps in Workspace Settings → Integrations.

Kind
Chat bridge
Where to set it up
Workspace Settings → Integrations
Plan
All plans
Agent roles
planning, summarizer
Verified
1 Oct 2026

Setup steps

  1. Create a bot account. In Mattermost, create a bot account, copy its access token, and note the IDs of the team and of every channel the bot should serve.
  2. Open the Integrations tab. As a workspace owner, open the Integrations tab of Workspace Settings and scroll to the chat bridge panels at the bottom.
  3. Fill in the connection. Enter "Server URL", "Bot token", "Team ID" and "Channel IDs" as a comma-separated list.
  4. Save and let DevFlow verify. Click "Save". DevFlow checks the address, calls /api/v4/users/me with the token and refuses the save with "could not authenticate bot token" when that call fails; on success the listener starts at once.

What it does

Unlike a webhook integration, DevFlow opens an outbound WebSocket to /api/v4/websocket on your server and sends the bot token as its authentication challenge. If the socket drops, the listener reconnects after 1 second and doubles the wait on each failure, up to 30 seconds.

Only posted events count, and only when the post mentions the bot or replies inside a thread. Replies go back through the REST endpoint /api/v4/posts, in the same thread as the question.

A first mention gets an answer from the planning role, which reads the default branch of the workspace's first repository with Read, Grep and Glob for up to 3 minutes. Replying go then turns the conversation into a task, and the thread receives the planner's questions, the plan with a link and the final pull request links.

Each author is identified by the email of their Mattermost account, read through the bot. DevFlow rejects an unverified email by default, because an address a user can set freely must not grant someone else's DevFlow identity.

The server address is checked twice: when the connection is saved, and again for each dial, so a later DNS change cannot point the bot at an internal host.

Every outbound post is defanged first: @channel, @here and @all in agent-written text get a zero-width space, so a plan or a title can never notify a whole channel.

If an exploration fails, or the workspace is over its monthly budget, the thread gets a short apology pointing to DevFlow instead of an answer. A second message that arrives while an exploration is still running does not start another one.

Requirements

Limits

FAQ

Does the DevFlow Mattermost bot need an incoming webhook?

No. The bot connects out from DevFlow over a WebSocket, so your Mattermost server never calls DevFlow; an incoming webhook is needed only for DevFlow's separate Mattermost notification channel.

Who stays in control when a DevFlow task starts from Mattermost?

The people in the thread where the DevFlow task started. They answer the planner's questions and approve the plan by reply, and marking the task done stays a human action, by replying done or from DevFlow itself.

Can DevFlow post Mattermost notifications as well?

Yes. In DevFlow's Workspace Settings → Notifications, a Mattermost notification channel takes an incoming webhook URL and receives events such as plan ready, subtask failed and task done.

Sources

Every fact above comes from these files in the DevFlow repository.