Slack to Matrix bridge with mautrix-slack

Bridging Slack to Matrix with mautrix-slack during a transition

Many teams moving to a self-hosted Matrix homeserver cannot switch off Slack on day one. People still work in Slack channels, partners sit in Slack Connect channels, and group and direct messages carry context that nobody has moved yet. mautrix-slack is a Matrix-Slack puppeting bridge, based on slack-go and licensed under AGPL-3.0, that lets Matrix users reach Slack channels, Slack Connect channels, group DMs and 1:1 DMs from a Matrix client. The supported method is to run the bridge alongside a Matrix homeserver that you operate, so that bridged traffic stays inside infrastructure you control. The bridge is a transition tool. It carries live conversation in both directions for as long as both platforms are in use. It is not a migration of Slack history into Matrix, and you should not plan the cutover date on the assumption that old Slack messages will appear in Matrix rooms. Treat history as a separate question with its own export and retention decision, and confirm with the project what pre-login message history the bridge reads in your configuration. Matrix.org lists bridges for Slack, IRC, WhatsApp, Telegram, Signal and email under its bridges directory, so mautrix-slack sits in a category of bridges with a shared pattern: a service account or puppet identity on each side, and a mapping of rooms between them. The feature set is set by the project's own roadmap, which covers text, formatting, mentions, media, files, edits, threads, reactions, typing status and deletions in both directions. Items marked as planned or in progress may change, so check the current roadmap and the release you intend to deploy at build time, not when the plan was written. For the decision itself, ask three questions early. Which Slack channel types must stay reachable, and does your Slack workspace permit the token login the bridge needs? Which features do your teams rely on, such as threads or file sharing, and are those listed as supported in both directions? And who owns the bridge account on the Slack side, since its access follows that person's workspace permissions and its activity will appear in Slack audit records. Answering these first prevents a rollout that works for plain text and fails for the threads your people actually use. Plan the exit as well as the entry. A bridge that is easy to start can become permanent by default. Record a retirement criterion, such as the date when remaining Slack channels are archived or when the last active group DM closes, and plan which rooms will be kept as read-only records. Confirm the bridge's upgrade path and database requirements for your Matrix homeserver before the transition begins, so that the bridge does not hold back Synapse upgrades later.

What you need before installing mautrix-slack

mautrix-slack sits between a Matrix homeserver you operate and Slack workspaces that other organizations and your own admins control. Most of the preparation is confirmation work, so each card names the dependency, who can confirm it, and what to check before anyone edits a configuration file.

Matrix homeserver release and runtime

This page assumes Synapse, which registers the bridge as an application service. Confirm the Synapse release your team will run against its upgrade notes, since platform floors change between releases. Synapse 1.142.0 and later require Python 3.10 or newer, so the homeserver host must meet that floor. Confirm the release choice with your platform team before installation.

PostgreSQL version and database role

Synapse documentation recommends PostgreSQL for production, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. Check this floor against the release chosen for the homeserver, then ask your database team for a dedicated database and role for Synapse that backups cover. Confirm in the mautrix-slack repository whether the bridge needs its own database and what it stores there.

Slack workspace admin approval

Installing the bridge against a Slack workspace requires approval from a workspace owner or admin. Ask that person which apps and integrations the workspace permits, and whether they will approve mautrix-slack before installation begins. Record the approval and the scope they agreed to, because the bridge will act with the access of the accounts that sign in.

Slack users who will sign in

Each person whose Slack conversations will be reachable from Matrix must sign in with their own Slack account. Ask your identity or HR team for the list of people in scope, and check with the workspace admin whether guest, restricted or deactivated accounts can sign in. Users who are not in the list will not see their conversations bridged, so confirm the list before rollout.

Slack Connect partner workspace policies

Slack Connect channels are shared with another organization's workspace, and that partner's policies can limit what a bridged account may do in those channels. Ask the partner's admin whether external users and integrations are allowed in shared channels, and record the answer. Confirm your own workspace policy as well, because both sides apply their rules to the same conversation.

Host, network access and stable domain

The bridge runs from the Docker setup documented in the mautrix-slack repository, on a host that needs outbound network access to Slack. Synapse also needs a stable domain name, because the server name determines how user IDs and room IDs are written and changing it later is disruptive. Confirm firewall rules, DNS records and the Docker host standard with your network and platform teams before installation.

How the puppeting model shapes what users see

The most important thing to understand about mautrix-slack is that it works as a puppeting bridge. It does not act as one shared service account that sees everything the bridge can reach. Each Matrix user who connects their Slack account acts through that account, so what that person sees in Matrix is limited to what they already can see in Slack. A user who is not a member of a private channel in Slack will not suddenly see it in Matrix because a colleague has connected. Before rollout, teams should confirm this behavior against their own Slack workspace settings and test it with a few accounts holding different memberships.

The bridge creates Matrix rooms, called portals, for Slack conversations on its own. A portal can appear when a user logs in with a Slack token, or when a message arrives in a conversation the user can access. Teams should not plan for a manual room-creation step for each channel. They should plan for the opposite problem: rooms appearing in Matrix faster than the change-management process expects. Decide in advance who will be told when portals are created, how room names and membership will be reviewed, and whether anyone should be asked to clean up rooms that are no longer needed.

The mapping differs by conversation type, and the differences matter for communication plans. Standard Slack channels and Slack Connect channels, which are shared with people in other organizations, are both bridged, so external participants' messages will appear in Matrix rooms. Group DMs and 1:1 DMs are bridged through the same per-user model, which means a direct conversation is visible on the Matrix side only to the Slack account that holds it. Confirm with a pilot group how Slack Connect membership and DM participants are represented in Matrix before you tell staff which conversations will move.

Conversations that a user cannot see in Slack, including private channels they have not joined, archived channels they have left, and any history the user cannot open, should be treated as out of reach for that user in Matrix. The roadmap lists reading pre-login message history as a feature, so teams should not assume older history will be available on day one. Ask the implementer to document, for each conversation type, what history a newly connected user will see and what they will miss.

Because each connection is tied to a user's own Slack session, the bridge's security boundary is that session, not a central credential. Any control on Slack access, such as session lifetime, device approval, token revocation when someone leaves the organization, or a Slack admin's ability to restrict apps, directly changes what the bridge can expose. The security section of this page covers how to set those controls, but this model means identity offboarding in Slack must be part of the bridge runbook from the start.

How to configure mautrix-slack in order

This sequence takes the bridge from version checks through a pilot user and a second user, with a concrete check at each step. When it is finished, the team knows that the homeserver registration, the Slack login, the portal scope and two-way messaging all work before wider rollout.

Confirm homeserver and bridge versions
The team, together with whoever runs the homeserver, records the Synapse release it will run and the mautrix-slack release it intends to deploy. Check the Synapse upgrade notes for platform floors, since Synapse 1.143.0 and later require PostgreSQL 14 or newer and 1.142.0 and later require Python 3.10 or newer. Confirm the bridge release and its Docker setup in the mautrix-slack repository and its documentation. The step is done when both versions are written down and each meets the floors in the current documentation.
Provision PostgreSQL and the bridge host
The platform team creates a PostgreSQL database and a dedicated role for the bridge, then prepares a host that can reach the homeserver and make outbound connections to Slack. Keep the bridge database separate from the Synapse database so each can be backed up and restored on its own schedule. Confirm the PostgreSQL version against the bridge documentation before going further. The step is done when a connection test from the bridge host succeeds using the bridge role.
Generate the bridge configuration and registration file
Generate the default configuration and registration file from the bridge, then set the homeserver address, the server name, the bridge domain and the permissions that decide which Matrix users may use the bridge. The server name must match the server_name in your Synapse configuration, because users and rooms are identified by it. Grant permissions only to the small group that needs access during the pilot. The step is done when the configuration loads without errors and the registration file contains the tokens and namespaces the homeserver needs.
Register the bridge with the homeserver
Add the registration file to the Synapse appservice configuration, make sure the homeserver can read it, and restart Synapse through your normal change process. Read the Synapse startup log for the appservice being loaded. The step is done when the homeserver reports the bridge as registered and the log shows no errors about it. Do not continue if Synapse logs a registration error, because later steps will fail in ways that are harder to trace back to this one.
Start the bridge with Docker
Start the bridge using the Docker setup from the mautrix-slack repository, mounting the configuration and registration file you generated and pointing the bridge at the PostgreSQL database. Confirm that the container is running, then read its logs for a successful database connection and a successful connection to the homeserver. From a Matrix account on your server, send the bridge bot a help or status command. The step is done when the bot responds and the logs show no repeated errors.
Log a pilot user in with Slack
A pilot user agreed in advance starts the Slack login from the bridge bot and completes the token login. The bridge creates portals automatically on token login or when a message arrives, so confirm which conversations are likely to appear before the pilot begins. Check that the expected portal rooms show up in the pilot user's Matrix client. Send one test message from Slack to Matrix and one from Matrix to Slack. The step is done when both messages arrive in the correct portal.
Scope conversations and users included
Decide which Slack channels, Slack Connect channels, group DMs and 1:1 DMs the bridge may serve, and which Matrix users may use it, then write those rules into the bridge configuration. Review the pilot portals and remove any that fall outside the agreed scope. Record the permitted user list so an access review can reproduce it. The step is done when a message from a conversation outside scope creates no new portal and the permitted users match the approval record.
Run a second user through the flow
Repeat the login and the two-way test with a second user, using the same permissions and scope rules, and note any difference in behavior. Test the message features your staff depend on, such as edits, threads, reactions, file sharing and deletions. Check each against the feature list in the mautrix-slack roadmap and your bridge version, because the roadmap distinguishes planned work from what is available. The step is done when the second user's test messages cross in both directions and each feature result is recorded.

Which message features cross the bridge in each direction

Messages posted in a bridged Slack channel, Slack Connect channel or DM reach the mapped Matrix room through mautrix-slack. The roadmap lists each feature below for this direction, so read the list as the scope to confirm before you rely on any item.

Text, formatting and mentions: Plain messages, Slack formatting and user mentions are listed for this direction. Check how mentions resolve to Matrix users in your test rooms.
Media and files: Images, attachments and other files are listed for this direction. Test file size and type handling with representative attachments from your own workspace.
Edits, deletions and reactions: The roadmap lists these for both directions. Confirm that an edit or deletion made in Slack appears in Matrix in the way your users expect.
Threads and typing status: Threads and typing status are listed for this direction. Confirm how thread replies display in the Matrix room and whether typing indicators appear.
Pre-login message history: Reading history from Slack before the bridge logs in is listed on the roadmap. Confirm whether your transition depends on it, because it determines how much older Slack content users can see in Matrix.

Mark each item implemented, partial or planned by checking ROADMAP.md on the publication date before you cite it.

How Slack objects map to Matrix objects

This table compares each Slack object with the Matrix object mautrix-slack creates for it, and lists what to check in a pilot. Read each row as the mapping the bridge documents, then confirm the behavior in your own workspace. The main takeaway is that identity matching, room permissions and message linking depend on how your Slack and Matrix environments are configured, so test them before any team moves.

Slack object	Matrix object	What to confirm
Slack user identity	Matrix user created through the bridge login, using each person's own Slack token	How Slack accounts match Matrix user IDs, and how each person completes the bridge login in your pilot
Slack channel	Matrix portal room, created on token login or when the first message arrives	Room names, topics, membership and who can post in each portal room
Slack Connect channel	Matrix portal room that includes members of the external organization	Whether external members are identified in the room, and whether that matches your external sharing policy
Group DM and 1:1 DM	Matrix portal room for the conversation	Which participants appear, who can read the history, and when a new portal is created
Message edits, reactions and deletions	Matrix events linked to the original Slack message ID	Which of these the roadmap lists as implemented in your version, and how each appears on both sides

Security settings and hardening for the Slack bridge

A bridge between Slack and Matrix holds Slack credentials, mirrors message content into a second system, and needs network reach into both platforms. The controls below cover the bridge itself, the Matrix side, the network path, and the Slack workspace settings that the workspace admin must approve before the bridge can run safely.

Protecting stored Slack tokens and the database

After a user logs in, mautrix-slack keeps Slack session tokens in its database so it can reconnect without prompting again. Anyone who reads that database can act as the bridged Slack user. Restrict database access to the bridge service account, encrypt the volume and backups that hold it, and decide in advance how tokens are revoked when a bridge user leaves or a host is retired. Confirm the exact storage location and token format with the mautrix-slack setup documentation for your version.

Limiting who can log in and what gets bridged

Set the bridge permissions so only approved Matrix users can attach their Slack accounts, and so only named Slack channels, Slack Connect channels and DMs are portaled. Because portals are created automatically on token login or when a message arrives, an unrestricted setup can pull in conversations nobody reviewed. Write down who may log in, which conversation types are allowed, and who approves exceptions. Confirm the permission keys and their defaults in the bridge configuration reference.

Restricting bridge admin rights on the homeserver

Bridge administration covers creating bridge rooms, managing logins and changing configuration, and it should not sit with the general homeserver admin group by default. Use a separate bridge operator role, keep the bot account's power level in each bridged room at the minimum it needs, and review membership of both groups on a fixed schedule. Confirm with your homeserver deployment which admin APIs the bridge bot needs before granting any of them.

Segmenting the bridge host and its outbound access

The bridge needs outbound HTTPS access to Slack and a connection to the Matrix homeserver, and it needs nothing else. Place it in a segment that allows only those destinations, deny inbound access from user networks, and log outbound connections. Record which Slack endpoints your network team must allow after confirming them against the current mautrix-slack documentation, since these can change across releases. Keep the bridge's database and its Matrix connection on private addresses.

Logging and retention of bridged message content

A bridge copies every bridged message into Matrix room history, and Matrix retention settings may differ from Slack's. Decide what the bridge logs at debug level, keep bridge logs free of message bodies and tokens where the version allows, and set a retention period for bridged rooms that matches your data policy. Confirm with your legal and records team which copy is authoritative during the transition and how deletions propagate, because the roadmap lists deletions as bridged in both directions but the timing depends on the version you run.

Slack workspace controls to review with the admin

Some protections sit in Slack, not in the bridge. Ask the workspace admin to confirm whether third-party app installation requires approval, which app the bridge uses to authenticate, and whether Slack Connect invitations from external organizations are allowed into the bridged channels. Also confirm who may generate user tokens and whether the workspace audit and export features cover the accounts that will be bridged. Record each answer with its date, since workspace policies change independently of the bridge.

How to test the bridge before users depend on it

Test mautrix-slack with a small pilot group and a fixed set of conversations before anyone relies on it for daily work. Write the test plan down first, including the four conversations, the pilot users and the Slack account each pilot user signs in with. Use one Slack channel, one Slack Connect channel, one group DM and one 1:1 DM. Each type creates portals and membership differently, and the Slack Connect channel brings external workspace members into the picture, so a pass on ordinary channels does not show that the others work. Choose pilot users who already use each conversation type every day, so that failures show up in the work they actually do.

For each conversation, test every feature the team relies on in both directions. Start from the feature list in the mautrix-slack roadmap, which covers text, formatting, mentions, media and files, edits, threads, reactions, typing status and deletions. Send each test message from Slack and from Matrix, then check that it arrives, renders correctly and keeps its identity when edited or deleted on the other side. Confirm current support against the project's ROADMAP.md and your deployed version, not against memory. If the team needs history from before the bridge was logged in, test the pre-login history feature separately and confirm it on your build.

Run failure tests while conversations are active. Restart the bridge in the middle of a conversation, then send messages before, during and after the restart, and check for lost, duplicated or out-of-order messages. Next, let a Slack token expire or revoke it deliberately in a test account. Record how the bridge reports the failure, whether pilot users see any notice, and how the team restores the connection through a fresh token login. Also test a conversation that has no portal yet, since portals are created on token login or when the first message arrives, and confirm where the room appears and who can see it.

Check portal visibility for users who should not see a conversation. Sign in as a Matrix user who is not a member of the Slack conversation and confirm that the room does not appear in the room list, cannot be joined without an invitation and shows no history. Check the same for invitations, the room directory and any admin views you expose. For Slack Connect, confirm what external participants can see through the Matrix side compared with Slack. Confirm with the mautrix-slack documentation and in your own environment how membership is mirrored, and do not assume that Slack's own access rules carry over unchanged.

Record each result per feature and per conversation type, with a clear pass or fail, the version tested and any workaround. Before rollout, agree in writing with the sponsor and the security owner which gaps are acceptable during the transition and which block it. A missing reaction type in a group DM may be tolerable for a defined period, while lost messages after a restart or a visible room to an unauthorized user should block rollout. Retest every blocking item after the fix and keep the signed results with the change record.

Why bridged rooms and messages fail

This table pairs each symptom a Slack bridge operator is likely to see with its usual cause and the check that confirms the fix. Read it from the symptom column, then work the check before changing configuration. Most failures trace to login state, portal creation, Slack-side access rules or the Synapse appservice connection rather than to the bridge code itself.

Symptom	Likely cause	Fix and confirming check
Portals do not appear after login	Portals are created on token login or when a first message arrives, so an idle account or a channel nobody has posted in may show nothing yet	Post a test message in the Slack channel and confirm a portal room is created. Check the bridge log for portal creation entries for that channel ID
Messages missing in one direction	The bridge appservice registration on the homeserver may be incomplete, or the bridge account lacks the rights its configuration expects in Slack	Confirm the appservice registration file is loaded by Synapse and that the bridge can reach the homeserver. Send one message each way and check the bridge log for send errors
Slack Connect conversation visible in Slack but not in Matrix	Shared channels from another organization depend on the signed-in Slack user being a member and on the conversation being accessible to that account	Confirm the bridged Slack account is a member of the Slack Connect channel in Slack itself. Then check the channel ID the bridge logs when it lists conversations for that account
Edits or deletions not mirrored	Edits and deletions are listed on the mautrix-slack roadmap for both directions, so support depends on the release in use and may be partial	Check the repository roadmap and release notes for the release you run. Make one edit and one deletion in a test portal and compare the bridge log against the Matrix timeline
Media fails to cross	Uploads and downloads depend on the homeserver media repository limits, file type handling and the bridge's ability to fetch Slack files with the signed-in account	Send a small image and a small document in each direction. Check the homeserver media size limit and the bridge log for fetch or upload errors on the file URL
Bridge fails to start after a homeserver change	The registration file, server name or homeserver address in the bridge configuration may no longer match the new Synapse setup, or the database schema changed during the upgrade	Compare the server name and homeserver address in the bridge config with the homeserver config. Read the Synapse upgrade notes for the version you moved to, then confirm the bridge starts and logs a successful connection
Tokens stop working after a Slack-side policy or session change	Slack may end sessions or restrict third-party access when administrators change workspace policies, password rules or app approvals	Check the bridge log for authentication failures and the Slack workspace app or session settings with a Slack administrator. Sign in again through the bridge login command and confirm portals resume
Bridge runs but rooms show stale history	Reading history from before login is listed as a roadmap item, so older Slack messages may not appear in Matrix	Confirm the message history expectation against the roadmap for your release. Post a new message in Slack and verify it appears in Matrix before judging the bridge as faulty

Questions teams ask before bridging Slack to Matrix

What drives the cost of a mautrix-slack bridge project?

The main drivers are how many Slack workspaces, channels, Slack Connect conversations, group DMs and users are in scope, because each adds mapping, testing and support work. The state of your Synapse homeserver also matters. A production setup on PostgreSQL, a working reverse proxy and a settled server_name make a bridge simpler to add, while a homeserver that needs upgrades first adds work. Testing scope is another driver, especially for formatting, media and edit behavior. Finally, your team's Matrix operations skills determine how much support you will need after launch.

Ask the written quote to separate:

One-time work: design, installation, pilot testing and documentation
Recurring work: monitoring, upgrades, credential maintenance and support
Assumptions about workspaces, conversations, users and testing depth

How long does a Slack to Matrix bridge project take?

The duration depends mainly on pilot scope and on how quickly approvals arrive. A pilot limited to a few conversations with named owners moves faster than a project that covers every workspace at once. Approvals from the Slack workspace owner, your security and legal reviewers, and the team that will host the bridge often set the pace more than the technical build does. Testing against real conversation types, including Slack Connect channels and DMs, adds time when those types are included in the pilot.

Deployment timelines should appear in the written scope, with milestones for the pilot, the review gate and the wider rollout. Ask for those dates in writing rather than relying on a general estimate. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

What does a bridge project need from our team?

The project needs several named people before work begins:

Slack admins who can authorize the integration and confirm which workspaces are in scope
Matrix admins who manage the homeserver, DNS, certificates and the bridge's appservice registration
Conversation owners who choose the pilot channels and confirm who should be reachable from Matrix
A host with the compute, storage and network access the bridge needs, in infrastructure you control
A decision-maker on message retention, meaning how long bridged content is kept on each side

Also name a technical owner for ongoing operations. Without that person, the bridge tends to stop being maintained after the project ends.

Can our internal team run mautrix-slack without outside help?

Yes, a team with solid Linux, container and Matrix administration skills can install and run mautrix-slack by following the project's setup documentation, which includes a Docker setup. The harder questions are usually operational: whether the bridge's data handling meets your policies, how you will test before wider rollout, and who responds when Slack or Matrix changes break something. The project is AGPL-3.0 licensed, so your legal team should review license obligations if you modify it.

A partner usually adds value in pilot design, security review of the deployment, documented runbooks, and a supported upgrade path. Whether that is worth paying for depends on how many people in your organization can own the bridge long term. DeployOpen can plan and implement the work in infrastructure you control, with scope agreed in writing first.

Does a Slack bridge replace migrating our Slack history to Matrix?

No. A bridge keeps conversations reachable from Matrix while people transition, but it does not move your existing Slack archive into Matrix rooms. The project's roadmap lists reading pre-login message history from Slack as a planned item. Before you plan around that capability, confirm with the mautrix-slack maintainers whether it is available in the version you intend to run and what it covers.

If you need a complete archive in Matrix, treat history migration as a separate workstream with its own scope, data mapping, testing and sign-off. Ask any vendor to state in writing which history is imported, which stays in Slack, and how your legal and records teams will access the archive afterward.

Which Slack message features cross the bridge in each direction?

The project's roadmap lists text, formatting, mentions, media and files, edits, threads, reactions, typing status and deletions as features to bridge in both directions. Roadmap items are not guarantees, and support can differ by feature and by direction, so check the current state of each item against the version you plan to deploy. Test the features your teams use most, such as threads, file sharing and reactions, during the pilot.

Ask the implementation scope to list each feature, the expected behavior in each direction, and the test cases used to confirm it. Document known gaps so users understand what they will see when they work across both platforms.

What should we check on our Synapse homeserver before adding a bridge?

Start with the homeserver's version and platform floors. Synapse recommends PostgreSQL for production, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer, so confirm your versions against the upgrade notes for the release you run. Check that server_name is set correctly, because it determines how users and rooms are identified and cannot be changed casually later.

Review your backup and restore process, your monitoring, and your upgrade history. Synapse upgrade notes warn that rolling back can be difficult because of database schema changes, so plan a tested backup before any upgrade. Confirm that the bridge's host can reach your homeserver and that your firewall and federation settings match your policy.

Are Slack terms and data handling a concern when bridging?

Yes. Bridging copies message content between Slack and Matrix, so the data leaves Slack's control and lands on infrastructure you run. Whether that is permitted depends on your Slack plan, the terms that govern your workspace, your data classification rules and any contracts with customers or regulators. Those questions belong with legal counsel and the workspace owner, not only with the engineering team.

Ask for a written review covering which workspaces and conversations are in scope, who can authorize the integration, how bridged data is stored and retained on each side, who can access the bridge's database and logs, and how credentials are rotated. DeployOpen can document the data flows and controls that the review needs, but it does not issue legal opinions or compliance attestations.

How DeployOpen scopes and delivers a Slack to Matrix bridge

DeployOpen scopes mautrix-slack as a fixed-scope engagement, then builds, tests and documents a bridge that keeps Slack channels, Slack Connect channels and DMs reachable from your Matrix homeserver during a transition. The work runs in infrastructure you control, and the feature list is checked against the bridge's current roadmap before anything is promised.

How we scope

The written scope names which Slack workspaces, channels, Slack Connect channels and DM types the bridge will carry.
We confirm which message features cross in each direction because the roadmap describes features the current release may not fully cover.
Fixed-scope engagements are agreed in writing before work starts, and ongoing support is available as a retainer.

How we build

We deploy mautrix-slack from its documented Docker setup, on the Matrix homeserver and hosts you specify.
We configure the Slack connection, portal creation when a message arrives, and the bridge's Matrix-side settings.
We test text, formatting, media, edits, threads, reactions and deletions in both directions against a staging workspace.

How we hand over

Handover includes a runbook covering deployment, configuration, upgrades, and the bridge's database backup and restore steps.
Your team receives documentation of which Slack users and tokens the bridge uses, and how to revoke them.
Your team receives a record of which message features were tested, with results and any known gaps.

How we support

Ongoing support can cover bridge upgrades, monitoring of the bridge process and triage of message sync issues under a retainer.
Retainer scope is agreed in writing, including who responds to issues and how changes to Slack access tokens are handled.
Confirm with your Slack admins which plan and settings your workspace needs before the bridge goes live.

Bridging Slack and Matrix with mautrix-slack