> ## Documentation Index
> Fetch the complete documentation index at: https://filament.getgalaxy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Slack

> Read conversations, messages, thread replies, files, and workspace metadata from Slack

The Slack source reads workspace information, users, conversations, messages,
thread replies, files, bookmarks, and pins visible to its token. It is built
with an [HTTP manifest](/pages/connectors/building-a-connector/http-manifests)
and is **alpha**, so its resources and columns may change between releases.

## Configuration

| Field | Scope | Default | Description |
| - | - | - | - |
| `token` | Connection | | Required. Secret. Bot or user OAuth token. |
| `conversation_types` | Connection | `[public_channel]` | Conversation types to include. Any of `public_channel`, `private_channel`, `mpim`, `im`. |

## Resources

`team` is a cardinality-one snapshot of the workspace. `users` and
`user_groups` are top-level lists. `conversations` uses `users.conversations`
rather than `conversations.list`. That gives a membership-aware inventory,
because `conversations.history` rejects channels the bot can discover but has
not joined. It captures each channel id, and `messages` (one history walk per
conversation), `bookmarks`, and `pins` fan out from it.

`thread_replies` fans out from a capture-only `threads` walk of
`conversations.history`, not from `messages`. Slack reveals new replies on an
old thread only through the parent message's `latest_reply`, and history has
no updated-since filter, so the walk reads every message in every enabled
conversation on every run. It emits nothing. `thread_replies` then calls
`conversations.replies` only for parents whose `latest_reply` is at or past the
saved replies watermark, so messages that never started a thread and threads
with no new activity cost no request. `files` is an independent top-level
list.

## Modes

All resources support full reads. If interrupted, a top-level resource resumes
after its last completed page. Children
(`messages`, `thread_replies`, `bookmarks`, `pins`) always restart with their
parent.

Three resources are incremental.

| Resource | Cursor field | Request parameter | Checkpoint key |
| - | - | - | - |
| `messages` | `ts` | `oldest` (query) | `messages_since` |
| `thread_replies` | `ts` | `oldest` (query) | `replies_since` |
| `files` | `created` | `ts_from` (query) | `files_created` |

All use the `numeric` comparator (Slack timestamps are epoch numbers) and
declare no overlap window. The cursor field is fixed by the manifest. Only a
lookback window is user-configurable, which the numeric comparator supports.
All conversations share one saved `messages` cursor, and all threads share one
saved `replies_since` cursor. For example, Filament may finish scanning a busy
channel after a newer message was posted to a quiet channel that it already
scanned. Without a lookback, that quiet-channel message can fall before the
next run's starting cursor. The same race applies to a reply posted in one
thread while a later thread is still being read. Configure a lookback of at
least one run's duration on `messages` and `thread_replies` if late arrivals
matter.

An incremental `thread_replies` run still walks the full history of every
enabled conversation to find threads that moved. On a Tier 3 token that is
about one request per thousand messages at fifty or more requests a minute.
Edits and deletions of messages and replies are never observed, because Slack
keeps the original `ts` and history exposes no change filter.

## Behavior

* **Auth**: bearer token from `token` on every request.
* **Errors**: Slack returns HTTP 200 with `{"ok": false, "error": …}` on
  failure, so the manifest declares an error envelope. Any response carrying
  an `error` field fails the run with that value as the message.
* **Pagination**: cursor paging via `response_metadata.next_cursor` for
  users, conversations, messages, and thread replies. `files.list` is the
  exception. It uses page-number pagination (`page`/`count`, 100 per page,
  bounded by `paging.pages`).
* **Rate limiting**: no client-side limiter is configured. The engine backs
  off on 429 responses using `Retry-After`. Use a token from an app you
  created in your own workspace. Since May 2025 Slack limits apps distributed
  commercially outside the Slack Marketplace to one `conversations.history` or
  `conversations.replies` request per minute with fifteen messages per page,
  which makes every message resource unusable at scale. Internal apps and
  Marketplace apps keep the standard Tier 3 limits.
* Every resource carries a `raw` remainder column preserving fields the
  manifest does not project.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.