Skip to content

Notifications & integrations

Add one or more notification destinations to a form (dashboard Workflow tab) and every accepted submission gets delivered to all of them. Availability by plan is on the pricing page; this page covers how each destination type works.

Destination types

TypeWhat it does
emailSends to a verified sender address on your account
discordPosts to a Discord channel via an incoming webhook URL
slackPosts to a Slack channel via an incoming webhook URL
telegramSends a message via a Telegram bot token + chat ID
webhookPOSTs the submission as JSON to your own endpoint, signed - see below
zapier / makeSame generic webhook delivery, wired up via a Zap/Scenario's own subscribe URL

Toggle any destination on/off from the dashboard without deleting it, or remove it outright.

Need more than one recipient? Add multiple destinations of the same type - e.g. two email destinations with different addresses, or two discord destinations for two different channels. Every enabled destination gets its own delivery attempt for each submission, so this is the supported way to notify several people or channels; there's no separate CC/multi-address field. Adding the same address/URL/chat twice as two destinations of the same type is rejected (DUPLICATE_DESTINATION) since it would just deliver the same submission there twice.

Discord setup

  1. Open the Discord channel you want submissions posted to.
  2. Click the gear icon next to the channel name (Edit Channel), then go to Integrations → Webhooks.
  3. Click New Webhook (or Create Webhook), optionally rename it and pick the channel.
  4. Click Copy Webhook URL.
  5. In BootForm, add a Discord destination and paste the URL into Webhook URL. The optional Bot name overrides the name Discord shows on each posted message.

Each new submission is posted as a message in that channel. Removing the webhook on Discord's side (rather than in BootForm) will cause deliveries to that destination to start failing - check the destination's Delivery log in the dashboard if messages stop showing up.

Slack setup

  1. Go to api.slack.com/apps and click Create New App → From scratch.
  2. Name the app (e.g. "BootForm") and select the workspace to install it into.
  3. In the app's settings sidebar, open Incoming Webhooks and toggle it On.
  4. Click Add New Webhook to Workspace, pick the channel to post to, and authorize.
  5. Copy the generated webhook URL (starts with https://hooks.slack.com/services/...).
  6. In BootForm, add a Slack destination and paste the URL into Webhook URL.

A Slack incoming webhook is tied to one specific channel - to post to a different channel, create another webhook (repeat step 4) and add it as a separate BootForm destination.

Telegram setup

  1. Open a chat with @BotFather in Telegram and send /newbot, following its prompts to name your bot. BotFather replies with a bot token (looks like 123456:ABC-DEF...) - copy it.
  2. Add the bot to the chat, group, or channel you want notified. For a channel, add it as an administrator (Telegram requires this for a bot to post there).
  3. Find the numeric chat ID: the simplest way is to message @getidsbot from the same chat/group/channel and read the ID it returns, or send any message to your bot and check https://api.telegram.org/bot<token>/getUpdates for the chat.id field.
  4. In BootForm, add a Telegram destination with the bot token and chat ID from steps 1 and 3.

Delivery log

Each destination's Delivery log (in the dashboard's Workflow tab) shows its most recent 50 delivery attempts, newest first, 8 per page with Previous/Next to page through the rest, with status code, response time, and whether it ultimately succeeded. Older entries are removed automatically after 90 days, so this is a recent-activity view for troubleshooting - not a permanent record. Need a longer history? Export or archive delivery outcomes on your own end by watching the destination's own receiving endpoint.

Outgoing webhook signature verification

Every delivery to a webhook destination carries a BootForm-Signature header so you can confirm it genuinely came from BootForm:

BootForm-Signature: t=1700000000,v1=5257a869e7bfa9...

v1 is an HMAC-SHA256 of "{t}.{raw_request_body}", keyed with your destination's signing secret (shown once, in plaintext, when the destination is created - rotate it any time from the dashboard if it leaks). To verify: recompute the same HMAC with your stored secret and compare it to v1 using a constant-time comparison (e.g. Node's crypto.timingSafeEqual, Python's hmac.compare_digest) - a plain ==/=== string comparison leaks timing information an attacker can use to guess the signature byte-by-byte.

Zapier and Make

Both integrate through the same generic webhook mechanism above - connecting a Zap or Make Scenario gives BootForm a per-integration URL to deliver to, the same way a plain webhook destination does. Make can alternatively poll GET /forms/{form_id}/submissions?since=... for scenarios that prefer pulling over receiving pushes.

Google Sheets, Airtable, and Notion

Not available yet - there's no real delivery mechanism for any of these three, so they're not offered as a destination type in the dashboard. If you want submissions flowing into a sheet or database today, connect through Zapier or Make instead (both have a direct Google Sheets/Airtable/Notion action on their own side), or pull with the submissions API / a CSV/JSON export.