Slack Data Connector

The Slack Data Connector pulls message history from selected Slack channels via the Slack Web API, with cursor-based pagination and incremental loading. Each configured channel produces its own destination table, named after the channel. Messages with thread activity are enriched inline with their replies.

The connector can only access channels the BigPanda Slack bot has been invited to. Use channel-discovery to identify channels currently available to the bot.

Authentication

The Slack connector authenticates with a Slack bot bearer token (xoxb-...) issued to a dedicated BigPanda Slack app installed in your workspace. Provide the bot token to your BigPanda account team during setup. Tokens are stored securely on the BigPanda side and are not echoed back in connector configuration.

Sync preferences

Provide the following information about your sync preferences to BigPanda:

Required Configuration

Option	Description
Mode	Determine whether you’d like to set up an incremental or historical sync. Most organizations will use both modes. See the Streaming Modes section for more information.

Connector configuration

Field	Type	Default	Description
`start_date`	string	none	Start date as `YYYY-MM-DD` or ISO 8601. Interpreted as UTC midnight.
`end_date`	string	none	End date as `YYYY-MM-DD` or ISO 8601. Historical mode only. Interpreted as UTC midnight; same-day ranges are bumped to the next day to give a full 24-hour window.
`channels`	list	required	List of `{name, id}` channel pairs to ingest.
`query_limit`	int	`50`	Max API requests per rate-limit window. Slack Tier 3 endpoints allow ~50/min.
`rate_limit_timeout_ms`	int	`1000`	Wait time between rate-limited requests, in milliseconds.

The connector also respects Retry-After headers returned by Slack on 429 Too Many Requestsresponses, so transient rate-limit hits self-recover.

Channel discovery and configuration

Channels are configured as an array of {name, id} pairs. To discover channels available to the BigPanda Slack app, call the connector's channel-discovery endpoint:

GET /v1/udc/connections/{connection_id}/slack/channels

The response lists every channel the bot has been invited to, with both the human-readable channel name and the Slack channel ID. Use the returned IDs in the connector's channels configuration.

Example:

{
  "config": {
    "channels": [
      { "name": "general",     "id": "C08QDGX4741" },
      { "name": "engineering", "id": "C09ABC1234" }
    ],
    "cron_schedule": "*/10 * * * *",
    "start_date": "2026-01-01"
  }
}

Channel name normalization

The connector normalizes hyphens (-) to underscores (_) in Slack channel names when generating:

The connector's internal resource name.
The destination table name.
The sync cursor identifier in run reporting.

A channel named ops-alerts is consistently referenced as ops_alerts everywhere downstream. You do not need to reconcile the hyphenated Slack channel name with an underscored destination table name by hand.

Hyphen vs. underscore collision (rare)

Slack permits both hyphens and underscores in channel names, so in principle a workspace can contain two channels that differ only in punctuation. For example, ops-alerts and ops_alerts. Both names normalize to the same identifier (ops_alerts), so:

Their messages are written to a single, merged output table.
The sync cursor is shared between the two channels.

The connector does not detect this collision. In practice the case is extremely rare: teams pick one naming convention, Slack itself warns about similar channel names on creation, and you explicitly pick which channels to sync. If you do encounter it, rename one of the channels in Slack or exclude one from the connector configuration before running the connector. Contact BigPanda support if you need help reconciling pre-existing destination data after a collision.

Data considerations

Timestamps are UTC. The ts field is a Unix epoch timestamp in UTC (for example, "1777093380.123456"). All date boundaries (start_date, end_date) are interpreted as UTC midnight. Messages you see in the Slack UI in your local time zone may not line up with the UTC date range you configure. For example, a message that appears as 12:03 AM on April 26 in UTC+3 has a ts corresponding to 9:03 PM on April 25 UTC and falls outside a start_date: "2026-04-26" window.
Channels create single destination table with one row per message. Messages whose reply_count > 0 carry an inline replies array containing each thread reply (the parent message itself is not duplicated inside replies).Records are appended to the destination table on every run. The connector does not deduplicate at the destination. If you replay a window, configure your downstream consumer to deduplicate on ts.
Edits and reactions do not update ts. A message's ts is assigned on first post and never changes. Edits, reactions, pins, and similar post-creation changes do not modify it. Because the incremental cursor tracks ts, a message already ingested is not re-fetched on later runs even if its content has changed. The ingested data reflects each message's state at the time it was first fetched by the connector.
User mentions are stored as IDs. When a user is @-mentioned, the API returns the raw user ID rather than the display name. For example, the textfield carries <@U12345678> where the Slack UI shows @John Smith. Resolving these IDs to human-readable names requires the users.info endpoint and is on the connector roadmap as part of a metadata-refresh feature; it is not implemented today.
Same-day date ranges are supported. Setting start_date and end_date to the same day produces a full 24-hour UTC window. The connector bumps the end date to the next day at midnight UTC internally.

Troubleshooting

Bot cannot see a channel. Confirm the BigPanda Slack app has been invited to that channel by a workspace admin, and that the channel-discovery endpoint lists it.
401 Unauthorizedon connector test. Bearer token is invalid or has been rotated. Generate a fresh token and resupply it to your BigPanda account team.
Repeated 429 responses. Reduce query_limit or increase rate_limit_timeout_ms. Slack workspace-level rate limits are independent of the connector configuration.

Known limitations

Limitation	Detail
Messages only	User profiles and channel metadata are planned but not yet available.
No edit / reaction recapture	Already-ingested messages are not re-fetched even if edited or reacted to. The data reflects the state at first fetch.
No destination dedup	Each run appends. Deduplicate on `ts` downstream when replaying windows.
Bot membership required	The connector cannot read channels the bot has not been invited to, even if the workspace technically allows it.
Slack rate limits	Tier 3 endpoints allow ~50 requests/minute. Tune `query_limit` and `rate_limit_timeout_ms` if you are seeing repeated `429`s.

In this section: