Integrations overview

You can use Knock to power sophisticated cross-channel notification workflows for your end users, triggered by your application or by events sent to Knock from various customer data platforms (CDPs) like Segment and RudderStack.

We support the following channel types today:

• Email (such as Sendgrid, Postmark)
• In-app (such as feeds and toasts)
• In-app guide (such as banners, modals, and other in-product messaging)
• Push (such as APNs, FCM)
• SMS (such as Twilio, Telnyx)
• Chat (such as Slack, Microsoft Teams, and Discord)
• Webhook (send webhooks to custom channels or enable your own customers to configure webhooks in your product)

See a full list of supported channel providers.

Sources connect external services to Knock so that events from those services can trigger workflows, identify users, and manage objects and tenants. Knock supports three categories of source integrations:

• Incoming webhooks. Receive events from services like Stripe, Clerk, WorkOS, PostHog, and Supabase, or create a custom source for any webhook provider.

• CDP integrations. Forward track and identify events from platforms like Segment, RudderStack, Freshpaint, and Jitsu.

• Reverse ETL integrations. Sync warehouse data from platforms like Hightouch, Census, and Polytomic.

See the sources overview for configuration details, available actions, and debugging information.

Knock can also integrate with other tools for debugging, monitoring, and more, including the following:

• Datadog/New Relic. Receive Knock platform metrics for workflow & channel successes and errors.
• Segment/Heap. Send Knock notification events to downstream analytics tools.
• Vercel. Synchronize your Knock API keys to one or more Vercel projects.

Unlike most parts of the Knock model, your integrations live at the account-level. This means that when you create a new integration in Knock (say, SendGrid), you only have to create it once.

Once an integration is created, you can then configure it for each of your environments. There are a couple reasons we enable per-environment configuration for each.

• If you use different instances of a service for each of your environments, you can use the respective API key or destination webhook URL of each within your different Knock environments.
• You can provide environment-level config details to your channels. A common example is to add the suffix "(dev)" to the "From name" on all emails sent in your development environment.

If you want to use the exact same configuration for a given channel across all environments, you can use the "Copy from" button to duplicate your configuration across environments.

Sometimes you don't want a message to be sent in a local or testing environment, but you do want the ability to debug your messages and see what might have gone out.

Sandbox mode enables you to generate and preview messages for a given channel without delivering them. When sandbox is enabled, Knock will never send the request to your downstream provider, blocking all delivery. To gate delivery selectively rather than suppress it entirely, use channel conditions instead.

Sandbox mode is supported across all channel types (except for in-app) and can be enabled from the environment configuration view of a channel.

You can use channel conditions to place a condition on all instances of a channel within a given environment. As an example, if you want to ensure that your email channel only sends to recipients from your domain when it's executing in your staging environment, a channel-level condition would be great way to do that.

To add a condition to a channel's environment configuration, navigate to Channels and sources in your dashboard account settings, click on the channel you'd like to update, then click "Manage configuration" next to the relevant environment. Select "Conditions" in the modal that is opened.

Knock will execute your channel conditions for every step using the given channel across all your workflow runs. Knock will join these channel conditions with any step conditions via an AND, meaning both channel and step conditions will need to pass evaluation for the step to execute. You can then use Knock's conditions debugger to examine the evaluations of your channel conditions.

A channel group enables you to combine multiple channels of the same type into a single workflow step, using one notification template across all providers in the group. These are commonly used to combine push channels: instead of maintaining a separate channel step and template for APNs and FCM in every workflow, create a push channel group holding both connections and add it to your workflows as one push step.

Every channel group has a key that identifies it, along with these settings:

Field	Description
name	The human-readable name of the group.
channel_type	The type of channels the group contains, such as email, sms, push, chat, or http. Every channel in a group shares this type.
operator	Determines how many matching rules will result in message routing: any or all. When set to any, Knock routes to the first matching rule's channel only. When set to all, Knock routes to every matching rule's channel. Defaults to any.
channel_rules	The ordered list of rules that determine which of the group's channels Knock routes to.
visible_in	Where the group appears as a step destination: workflow, broadcast, or both. Defaults to both.

Each rule in channel_rules points to one of the group's channels and sets the terms under which Knock routes to it:

Field	Description
index	The rule's position in the group's ordered list.
channel_key	The key of the channel the rule routes to.
rule_type	Determines when the channel should be used: always, if, or unless. When set to always, Knock routes to the channel on every workflow run. When set to if or unless, Knock routes to the channel conditionally based on the values of variable, operator, and argument.
variable	The workflow property to evaluate. Not applicable for always rules.
operator	The comparison to apply between the variable and the argument. Accepts any of the condition operators, plus is_in_random_cohort for percentage-based cohort routing. Not applicable for always rules.
argument	The value to compare the variable against. Not applicable for always rules.

Random cohorts route recipients by percentage rather than by evaluating a property of the workflow run. Instead of making decisions based on who the recipient is, Knock assigns each recipient to a cohort and routes a percentage of them to a given channel. Splitting traffic this way enables you to shift volume to a new provider gradually rather than all at once. See our sender domain migration tutorial for guidance on how to use cohort routing to warm a new email sending domain.

A cohort rule takes the following values:

Field	Value
rule_type	if
variable	recipient.id
operator	is_in_random_cohort
argument	The cohort threshold, as a number from 0 to 100 with up to one decimal place, such as 12.5. With a single cohort rule, this is the percentage of recipients routed to this channel.

Knock hashes the recipient ID against the channel group to assign the cohort, so a given recipient consistently routes to the same channel across workflow runs.

A single cohort rule only determines routing for the recipients inside that cohort, so it should be paired with at least one additional rule to catch remaining recipients. Set the channel group's operator to any so that messages are routed to only the first matching rule. To route the remaining recipients, create an always rule pointing at the fallback channel. The fallback rule should be ordered after the cohort rule, so that only recipients not belonging to the cohort will reach it. With this configuration, Knock routes the cohort to the first channel and everyone else to the second.

To route traffic across more than two channels, add a cohort rule for each one. Every cohort rule in a group hashes against the same channel group, so each recipient holds a single position that all of the group's cohort rules compare against. Percentages act as cumulative thresholds rather than independent shares: a rule routes the recipients below its percentage that the rules ahead of it didn't already take.

Order your cohort rules from the smallest percentage to the largest, and end the group with an always rule:

Rule	argument	Recipients routed
Cohort rule pointing at channel A	12	The first 12%
Cohort rule pointing at channel B	42	The next 30%
always rule pointing at channel C	—	The remaining 58%

Set each percentage to the running total of the shares ahead of it. Channel B receives 30% of recipients because its rule is set to 42: the 12% already routed to channel A, plus its own 30%. Ordering a larger percentage ahead of a smaller one would prevent the smaller rule from ever matching, since every recipient below the smaller percentage is also below the larger one.

Find supported integration providers listed by channel type: Email, Chat, In-app, Push, and SMS. We're continuously adding new providers, so if you don't see your provider listed, please reach out to us at support@knock.app.