# Slack Destination Config Reference

Slack is a business messaging destination. RudderStack turns identify and track events into messages and posts them to Slack channels through incoming webhooks, from its servers.

In a Slack destination spec:

type: slack
definition_version: 1

Sample configuration

yaml

version: rudder/v1
kind: destination
metadata:
  name: slack-prod
spec:
  id: slack-prod
  display_name: Slack Production
  type: slack
  definition_version: 1
  enabled: true
  config:
    webhook_url: "{{ .SLACK_WEBHOOK_URL }}"

    incoming_webhooks_type: modern
    event_channel_settings:
      - name: Order Completed
        webhook: "{{ .SLACK_ORDERS_WEBHOOK_URL }}"
        regex: false
      - name: "^Trial (Started|Ended)$"
        webhook: "{{ .SLACK_GROWTH_WEBHOOK_URL }}"
        regex: true

    identify_template: "Identified {{name}}{{newline}}Plan: {{plan}}"
    event_template_settings:
      - name: Order Completed
        template: "{{name}} completed an order worth {{revenue}}"
        regex: false

    whitelisted_trait_settings:
      - email
      - plan
    deny_list_of_events:
      - Heartbeat

    connection_mode:
      web: cloud
      cloud: cloud
    consent_management:
      web:
        - provider: oneTrust
          consents:
            - analytics

The above example sets incoming_webhooks_type to modern, so each channel entry carries its own webhook instead of a channel name — see Channel routing. The webhook URLs are secrets, written as {{ .VAR }} references — see Secrets.

Config keys

config accepts only the keys listed below. The shared config key rules cover unknown keys, defaults, and immutability.

Slack accepts only identify and track events. RudderStack doesn’t deliver any other event type to it.

Connection

webhook_url

RequiredSecret

Type: string

Description: Slack incoming webhook URL. RudderStack posts every identify message here, and every track message that channel routing doesn’t send elsewhere.

Notes:

At most 100 characters, and must not contain line breaks.
Any value containing .ngrok.io is rejected.
Templates aren’t accepted in place of a literal; a template is measured as text against the same limits.

Supply it as a {{ .VAR }} reference rather than a literal — see Secrets.

See How do I obtain the incoming webhook URL?.

Channel routing

event_channel_settings sends track events to channels other than the one webhook_url posts to, and incoming_webhooks_type decides how. identify messages always go to webhook_url.

incoming_webhooks_type

Type: string

Default value: legacy

Description: How a matching event_channel_settings entry reaches its channel.

Notes:

legacy — RudderStack posts through webhook_url and names the entry’s channel in the message. The dashboard marks this method as due for deprecation.
modern — RudderStack posts to the entry’s own webhook, a URL from a Slack app with incoming webhooks enabled for that channel.

See Event channel settings.

event_channel_settings

Type: array of objects

Description: Routes track events to channels by event name. RudderStack uses the first entry that matches, and posts an event that matches none through webhook_url.

Notes:

name — event name to match. At most 100 characters, and must not contain line breaks. It also must not contain a parenthesized group that holds *, +, {, or | and is followed by *, +, ?, or { — such as (a|b)+ — even when regex is false.
regex — boolean. true treats name as a regular expression, which matches anywhere in the event name — anchor it with ^ and $ to match the whole name. Omit it, or set false, for an exact match.
channel — channel to post to when incoming_webhooks_type is legacy: a channel name such as #orders, or @user for a direct message. At most 100 characters, and must not contain line breaks. Quote it, since an unquoted # starts a YAML comment.
webhook — incoming webhook URL to post to when incoming_webhooks_type is modern. Same limits as webhook_url, including the .ngrok.io ban. Secret — see Secrets.
Templates aren’t accepted in place of a literal in these fields; a template is measured as text against the same limits.
Rudder CLI doesn’t check that an entry carries the field its webhook type uses. RudderStack skips an entry without it, as though its name never matched.

yaml

incoming_webhooks_type: legacy
event_channel_settings:
  - name: Order Completed
    channel: "#orders"
  - name: "^Trial (Started|Ended)$"
    channel: "#growth"
    regex: true

See Event channel settings.

Message templates

Both template keys take Handlebars expressions. Write each template in quotes: an unquoted value starting with { isn’t read as a string in YAML. Rudder CLI substitutes only {{ .VAR }} references, which start with a dot, so {{name}} reaches Slack as written.

A template can use:

Expression	Value
`{{name}}`	The user’s name — `traits.name`, or first and last name — falling back to their username or email, then to `User <userId>`, or `Anonymous user <anonymousId>`.
`{{event}}`	The event name. `track` only.
`{{property_name}}`, `{{properties.property_name}}`	An event property, where `property_name` is its name — such as `{{revenue}}`. `track` only.
`{{trait_name}}`	A trait, where `trait_name` is its name — such as `{{plan}}`. `identify` only. `{{traitsList.trait_name}}` works in both.
`{{traits}}`	The user’s traits as `key: value` text, limited to `whitelisted_trait_settings` when it’s set.
`{{propertiesList}}`	Every event property as `key: value` text. `track` only.
`{{newline}}`	A line break. Templates can’t contain literal line breaks, so this is the only way to write a multi-line message.

identify_template

Type: string

Description: Template for the message an identify event posts. When omitted, RudderStack posts Identified {{name}} followed by the user’s traits as key: value pairs, limited to whitelisted_trait_settings when it’s set.

Notes:

At most 1000 characters, and must not contain line breaks.
{{ path || fallback }} templates aren’t accepted in place of a literal; the value is measured as text against the same limits.

yaml

identify_template: "Identified {{name}}{{newline}}Plan: {{plan}}"

See Identify template settings.

event_template_settings

Type: array of objects

Description: Templates for the messages track events post, by event name. RudderStack uses the first entry that matches. An event that matches none posts {{name}} did {{event}}.

Notes:

name, regex — match events on the same terms as event_channel_settings.
template — the message template. At most 1000 characters, and must not contain line breaks.
{{ path || fallback }} templates aren’t accepted in place of a literal in these fields; the value is measured as text against the same limits.

yaml

event_template_settings:
  - name: Order Completed
    template: "{{name}} completed an order worth {{revenue}}"

See Event template settings.

Filtering

whitelisted_trait_settings

Type: array of strings

Description: Traits RudderStack lists in the default identify message and in {{traits}}. When empty, every trait is listed. A template can still name any trait directly.

Notes:

Each trait name is at most 100 characters, and must not contain line breaks.
Templates aren’t accepted in place of a literal; a template is measured as text against the same limits.

yaml

whitelisted_trait_settings:
  - email
  - plan

deny_list_of_events

Type: array of strings

Description: track event names RudderStack doesn’t post to Slack. A match is exact and case-sensitive, and RudderStack fails a matching event with a configuration error instead of posting it.

Notes:

Each name is at most 100 characters, and must not contain line breaks.
Templates aren’t accepted in place of a literal; a template is measured as text against the same limits.

Per-source keys

Both keys are objects keyed by the local source type — the tokens listed under Source types. A key naming a source type this destination doesn’t support fails validation.

connection_mode

Type: object

Description: Maps each source type you connect to the mode its events reach Slack in, using the modes in Source types.

Notes:

An entry is required for each source type you connect — see Connect a source.

yaml

connection_mode:
  web: cloud
  cloud: cloud

consent_management

Type: object

Description: Consent provider configuration per source type. The entry shape, accepted providers, and the rules on resolution_strategy and consents are shared across all destination types — see Consent management.

Source types

Slack accepts events from these source types in the mentioned connection modes:

Source type	Connection mode
`android`	`cloud`
`android_kotlin`	`cloud`
`ios`	`cloud`
`ios_swift`	`cloud`
`web`	`cloud`
`unity`	`cloud`
`react_native`	`cloud`
`flutter`	`cloud`
`cordova`	`cloud`
`cloud`	`cloud`
`warehouse`	`cloud`

Every source type is cloud only — RudderStack posts to Slack from its servers, never in device mode.

warehouse is the token a Reverse ETL source resolves to. Rudder CLI manages the destination’s warehouse entry — if the destination is connected to a Reverse ETL source, set connection_mode.warehouse: cloud in its spec, or apply removes it.

Rudder CLI can also declare the Reverse ETL connection itself, for the types listed under Supported destinations — see Manage Reverse ETL Connections using Rudder CLI.

The dashboard additionally offers Slack to AMP and Shopify sources. Rudder CLI doesn’t manage those connections, so amp and shopify are invalid here.

Connect a source

An event stream connection to this destination is checked against two rules at validate time.

The source’s type must be supported. A source’s type resolves to one of the tokens above before the check — a JavaScript source resolves to web, and webhook and server-side SDK sources resolve to cloud. Every type an event stream source can resolve to is supported here, so this check always passes.

The destination config must carry a connection_mode entry for that source type. This lives on the destination spec, not on the connection spec. Without it:

destination 'slack-prod' config has no 'connection_mode' entry for source type 'web'

Slack needs no additional config keys to connect a source of any type.

Secrets

webhook_url and each event_channel_settings entry’s webhook are the secret keys. Write each one you use as a {{ .VAR }} reference and supply the value at apply time:

yaml

config:
  webhook_url: "{{ .SLACK_WEBHOOK_URL }}"
  event_channel_settings:
    - name: Order Completed
      webhook: "{{ .SLACK_ORDERS_WEBHOOK_URL }}"

bash

export RUDDER_SLACK_WEBHOOK_URL="..."
export RUDDER_SLACK_ORDERS_WEBHOOK_URL="..."
rudder-cli apply

# or
rudder-cli apply --var-file secrets.vars.yaml

Note that:

rudder-cli import writes only the secrets the API returns, as {{ .VAR }} references, and leaves the others out. Add any secret key it leaves out, then supply the variables before you apply — see Secrets.
Each substituted value is validated like a literal, so a webhook URL still has to meet the webhook_url limits.

See How to Use Variable Substitution in Rudder CLI.

Changes by release

No changes since this type became available.

For changes across every destination type, see Destination Type Changes by Release.

See more

Slack Destination for incoming webhook setup, Handlebars expressions, and message examples
Destination Type Reference for Rudder CLI for the rules shared across destination types
Destination YAML Reference for the spec envelope