Skip to main content
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 and is alpha, so its resources and columns may change between releases.

​
Configuration

​
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. 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.