TL;DR. SlackBridge does not persistently store the body text of bridged messages. Each bridged message produces a small metadata record (Slack timestamp, Microsoft Teams message ID, channel IDs) that lives in encrypted key-value storage for seven days and is then automatically deleted. Sender names and message text are explicitly excluded from this record. A separate one-way hash of the message is stored for seven days as a lookup key. Nothing in the live threading path reads it back: a thread parent is resolved by stored message ID only. Message metadata and hash retention are fixed at seven days on every plan. Administrative audit events are retained for 30 days on the Free plan and 90 days on the Pro plan.
What's the short version?
SlackBridge is built so that the body text of your bridged messages is not persistently stored anywhere. Messages are forwarded between Slack and Microsoft Teams in real time. The bridge records only the small amount of metadata needed to keep replies threaded correctly, and that metadata expires automatically after seven days.
Three things to know:
- Bridged messages: the per-message record holds only ID metadata, never sender names or message text. Default retention seven days.
- Audit log: consent and connection events (consent grants, connection deletions, channel creation) are recorded; on the Pro plan they are written to a tamper-evident hash chain. Retention is 30 days on the Free plan and 90 days on the Pro plan.
- Tokens: Slack and Microsoft tokens are stored encrypted at rest. Removing a Teams connection deletes that tenant's Microsoft Graph tokens immediately. The Slack bot token is not removed by that action; email support@slackbridge.com to have it deleted.
What is stored, exactly?
For every message that crosses the bridge, SlackBridge writes one or two small key-value records:
| Record | What it contains | Retention | Purpose |
|---|---|---|---|
| Message mapping | id, channelMappingId, slackTs, slackChannelId, teamsMessageId, teamsChannelId, teamsParentMessageId, slackThreadTs, createdAt |
7 days | Find the Teams message that corresponds to a given Slack timestamp (or vice versa) when a reply needs to be delivered |
| Content fingerprint | A one-way BLAKE3 hash of sender_name plus the first 200 characters of the message text as the key, with the Slack timestamp as the value |
7 days | Written when a message is bridged; not read by the live threading path (see the threads-and-replies article) |
Separately from the per-message records:
| Record | What it contains | Retention | Purpose |
|---|---|---|---|
| Display-name and avatar cache | A person's display name or avatar image, keyed by their Slack or Teams user ID | Up to 24 hours, then expires | Show senders and mentioned users by name and picture on the other platform without looking them up on every message |
| Mentions roster | For each bridged channel with mentions on: each member's display name, the name they can be addressed by, and their Slack or Microsoft user ID, plus why anyone was left off. See how mentions bridge | Replaced after each complete refresh; kept until the channel mapping is deleted, including while it is paused | Deliver an @mention to the right person on the other platform |
| Operational logs | Identifiers (organization, channel, message), timings and error details. Never the text of bridged messages or the names of people in bridged conversations; account events can include the account holder's email address | Up to 7 days (Cloudflare) | Debugging and incident response |
| Error reports | The error, the request method and path, and the most recent operational log lines, so the same limits apply. Never request bodies, headers or query strings | Up to 90 days (Sentry) | Diagnosing failures |
What is not stored:
- The message body text. The bridge has the text in memory while delivering the message, but it never writes the text to KV or any database. The mapping record explicitly omits
senderNameandmessageText- this is enforced by a sanitization step in the storage helper. - The display name of the sender in any per-message record. Display names are held only in the 24-hour cache and the mentions roster above, never alongside message content.
- File attachments. File contents are never written to SlackBridge storage. Where file sharing is off, they are not fetched at all: the other side receives only an announcement naming the file and its type. Where it is on, the file is streamed through memory to the other platform and is still never written to disk here. Images pasted directly into a Teams message relay the same way: bytes pass through memory only and are never stored. Once it arrives, it is a normal file on the receiving platform and follows that platform's retention policy.
- Any kind of message archive that could be replayed later. SlackBridge cannot reconstruct the conversation; it can only resolve "this Slack message corresponds to that Teams message."
Audit-chain events
Administrative actions - admin consent grants, channel-mapping creation and deletion, connection re-consent, organization tier changes - are recorded as audit events. On the Pro plan they form a tamper-evident chain, where each event includes:
- A cryptographic hash of the previous event in the chain (BLAKE3)
- A monotonic sequence number
- The event's own hash, computed over its content plus the previous-hash
- The originating connection ID and (when available) organization ID
On the Pro plan, the hash chain makes tampering visible on verification: if a single event is altered, every subsequent event's hash becomes invalid unless all of them are rewritten as well. On the Free plan, the same events are recorded without chaining. Retention is set by plan: 30 days on Free and 90 days on Pro. It is not configurable per organization.
Tokens and ephemeral state
| Item | Lifetime | Notes |
|---|---|---|
| Slack bot token | Until you ask us to remove it | Slack bot tokens do not expire and are not deleted by removing a connection. Encrypted at rest. Email support to have it deleted. |
| Microsoft Graph access token | 50 minutes | Renewed automatically using the refresh token. |
| Microsoft Graph refresh token | Until you disconnect or re-consent | Encrypted at rest. |
OAuth state parameter |
10 minutes | CSRF protection on the OAuth callback. |
| Microsoft admin-consent state | 7 days | Longer because consent links are emailed and may not be clicked immediately. |
| Account-context cache | 15 minutes | Operator-side support-tooling cache; does not contain bridged-message text. |
| Public FAQ response cache | 1 hour | Keyed by intent hash; no user identifiers. |
| Health-alert dedup keys | 1 hour | Prevents duplicate "your bridge is down" emails for the same incident. |
Encryption and infrastructure
- All connections to and from SlackBridge use TLS 1.2 or higher.
- Tokens stored in KV are encrypted at rest using the underlying platform's managed encryption.
- Inbound Slack and Microsoft Graph webhooks are signature-verified before processing.
- The runtime is Cloudflare Workers with KV for state. There is no traditional always-on server with a disk to read.
How to remove your data
- Remove the connection from the dashboard. This immediately deletes the Microsoft Graph access and refresh tokens for that tenant, once no other connection is using it, and removes the channel mappings. From this point forward no new metadata is written. The Slack bot token is a separate step: email support@slackbridge.com with your organization ID and we will delete it and confirm.
- Wait out the TTLs, or
- Email support@slackbridge.com with your organization ID for a hard purge of metadata and audit records ahead of their natural expiration.
Disconnecting does not delete your messages from Slack or from Microsoft Teams - those continue to live in the source platforms under their own retention policies. SlackBridge has no copy to return or to delete.
Compliance posture
SlackBridge's data minimization (no message content stored, short retention windows, encrypted tokens, tamper-evident audit trail) is designed to make most compliance reviews straightforward. The combination of "we don't store the messages" and "we delete the metadata in seven days" answers the majority of GDPR, HIPAA-adjacent, and enterprise-vendor-review questions before they're asked.
For specific compliance documents (security overview, subprocessor list, data-processing addendum), email support@slackbridge.com.