> ## Documentation Index > Fetch the complete documentation index at: https://docs.barndoor.ai/llms.txt > Use this file to discover all available pages before exploring further. # Notifications > Subscribe to the events you care about and get them delivered where you actually look — in-app, email, Slack, Microsoft Teams, or a webhook. ## Overview Barndoor's platform generates a steady stream of change events — a server's connection breaking, a policy changing, an LLM budget being exhausted, a connected MCP server's tools changing underneath your policies. Notifications lets you choose which of those alerts get delivered, and where: your in-app inbox, your email, or an organization-wide destination such as a Slack channel, a Microsoft Teams channel, a shared mailbox, or a webhook. **Estimated time**: 5–10 minutes per channel ## Before You Begin You'll need: * A Barndoor account with **admin privileges** to manage organization-wide channels. Any user can manage their own personal notification settings. * For Slack delivery: permission to authorize the Barndoor Slack app in your workspace * For Microsoft Teams delivery: permission to add a **Workflows** incoming webhook to the destination channel * For webhook delivery: a public HTTPS endpoint that can receive a POST request ## Two Places to Configure Notifications Barndoor separates *your* notifications from *your organization's* alert destinations, and they are managed on different pages. | Page | Scope | What lives there | | ---------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Settings → Notifications** | Just you | Your in-app inbox and your account email, plus the alert types each one delivers | | **Alert Channels** | The whole organization | Shared destinations — an email address, a webhook, a Slack channel, a Teams channel — each with its own alert types | There is no separate "subscription" object to create. A channel *is* the subscription: you add a destination, then turn on the alert types it should receive. ## Alert Types Alert types are grouped into categories, and each carries an intrinsic severity you can filter by when picking which ones a channel receives. | Category | Alert type | Severity | | ------------------ | -------------------------- | -------- | | **MCP servers** | MCP server added | Info | | **MCP servers** | MCP server deleted | Info | | **MCP servers** | Connection broken | Warning | | **MCP servers** | MCP server tooling changed | Info | | **Access control** | Policy changed | Info | | **Access control** | Admin role change | Info | | **Access control** | Break-glass used | Critical | | **Usage & cost** | LLM threshold exceeded | Warning | | **Usage & cost** | LLM budget exhausted | Critical | | **LLM gateway** | LLM provider unavailable | Critical | | **LLM gateway** | LLM provider key rejected | Critical | | **LLM gateway** | API key revoked | Info | This list is enumerated by the platform, not hard-coded into the UI, so new alert types appear in the picker as they ship — no action needed to see them. Some alert types are released progressively and may not be visible to your organization yet; **MCP server tooling changed** (see [MCP Change Management](/how-tos/mcp-change-management)) is one of them. If a type isn't in your picker, it isn't available to your organization yet. **Connection broken** is scoped to the person whose connection failed. It's delivered to that user's own channels only — organization-wide channels never receive it, because a personal credential failure isn't an org-wide event. ## Delivery Channels Personal channels, on **Settings → Notifications**: * **In-app inbox** — the notification bell in the top bar * **Email** — sent to your account email address Organization-wide channels, on the **Alert Channels** page: * **Email** — an address you specify, such as a shared or on-call mailbox * **Slack** — posted to a channel by the Barndoor Slack app, which you authorize once per workspace * **Microsoft Teams** — posted into a channel as an Adaptive Card via a Teams **Workflows** incoming webhook * **Webhook** — a signed JSON payload POSTed to an HTTPS endpoint you control ## Add an Organization-Wide Channel 1. Sign in to your Barndoor portal and navigate to **Alert Channels**. 2. Click **Add channel**. 3. Choose the **Type** — Email, Slack, Microsoft Teams, or Webhook — and fill in its destination using the sections below. 4. Click **Create**. 5. Open the channel and, under **Subscriptions**, turn on the alert types it should receive. Filter by severity to focus the list. 6. Click **Test** to confirm delivery before you rely on it. A channel's destination is fixed once created. To point alerts somewhere else, delete the channel and add a new one. ## Setting Up Slack Delivery 1. In Barndoor, go to **Alert Channels → Add channel** and set **Type** to **Slack**. 2. Click **Connect Slack** and authorize the Barndoor Slack app for your workspace. You're returned to Barndoor with the Slack type preselected. 3. Pick the destination channel from the dropdown, then click **Create**. Slack delivery is a direct app integration, not an incoming webhook — there's no URL to copy or manage on the Slack side. The dropdown only lists channels the Barndoor bot is in. If the channel you want is missing, invite the bot to it in Slack with `/invite @Barndoor`, then reopen the picker. ## Setting Up Microsoft Teams Delivery Teams delivery uses a **Workflows** incoming webhook — the same mechanism Microsoft now recommends in place of retired Office 365 connectors. The workflow URL is the credential, so treat it like a secret. 1. In Microsoft Teams, open the destination channel, click **•••**, and choose **Workflows**. 2. Select the **"Post to a channel when a webhook request is received"** template and complete it. Teams generates an `https://` URL. Copy it. (See Microsoft's [guide to incoming webhooks with Workflows](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498).) 3. In Barndoor, go to **Alert Channels → Add channel**, set **Type** to **Microsoft Teams**, give the channel a **Label** you'll recognize, paste the URL into **Workflow URL**, and click **Create**. Alerts arrive as an Adaptive Card posted into the channel, so they persist in the conversation the way a Slack message does. Barndoor stores only the label and a fingerprint of the URL — the URL itself never comes back out of the API, which is why editing a Teams channel asks for it again. ## Setting Up Webhook Delivery 1. In Barndoor, go to **Alert Channels → Add channel** and set **Type** to **Webhook**. 2. Enter your endpoint as **Webhook URL**. It must be a public `https://` URL — localhost, private, and internal network addresses are rejected. 3. Click **Create**. Barndoor shows the **signing secret** once, at creation. Copy it then; it can't be retrieved later. Signing secrets are credentials — anyone holding one can forge a payload that looks like it came from Barndoor. Use **Regenerate secret** on the channel's page if you suspect a leak; the new secret is again shown only once, and the old one stops working immediately. ### Webhook Payload Barndoor follows the [Standard Webhooks](https://www.standardwebhooks.com/) specification. Each delivery POSTs a JSON body shaped like: ```json theme={null} { "type": "alert.mcp_server_tooling_changed", "timestamp": "2026-08-20T14:03:11.482913+00:00", "data": { "event_id": "01J9Z2QF7K8V3M4N5P6R7S8T9U", "severity": "info", "title": "Salesforce tools changed", "resource_name": "Salesforce", "occurred_at": "2026-08-20T14:03:11+00:00", "organization_id": "3f1c9e4b-7821-4a55-9d0e-6b2f8c1a7d34", "detail": {}, "link": "https://app.barndoor.ai/servers/…" } } ``` `type` is `alert.` followed by the alert type's identifier. `link` is present only when the alert has a destination in the portal. ### Verifying a Delivery Every request carries three headers: | Header | Contents | | ------------------- | ---------------------------------------------------------------------------------------------------- | | `webhook-id` | A unique id for this delivery, also used for idempotency | | `webhook-timestamp` | Unix seconds at send time | | `webhook-signature` | `v1,` followed by base64(HMAC-SHA256) over `{id}.{timestamp}.{body}`, keyed with your signing secret | The `detail` object's shape is specific to each alert type, and is the structured payload behind the alert — for **MCP server tooling changed**, it's the summary of what changed on the server. It never carries secrets, but it can carry your own tenant's resource names, so treat the endpoint as an egress point for your organization's data. ## Managing an Existing Channel Open a channel from the **Alert Channels** list to: * Toggle **Enabled** to stop and resume delivery without losing the channel's configuration * Change which alert types it receives, under **Subscriptions** * Send a **Test** message * **Regenerate secret** (webhook channels only) * **Delete channel** — the destination stops receiving alerts, and this can't be undone ## Your Own Notifications Go to **Settings → Notifications** to control what reaches you personally. Turn on **In-app inbox** or **Email**, then turn on the alert types each should deliver. Filtering by severity narrows the list you're looking at; it doesn't change what's already turned on. ## Managing Channels as Code **Coming soon**: a `barndoor_notification_channel` Terraform resource is planned, so webhook, Slack, Teams, and email channels can be declared and version-controlled the same way you already manage MCP servers and policies. Channels are configured in the portal for now — this page will be updated with a Terraform example once that resource ships. ## FAQ Yes, two ways. Each user controls their own in-app and email delivery under **Settings → Notifications**. For teams, add an organization-wide channel per destination — an on-call mailbox, a Slack channel per squad — and give each its own set of alert types. In-app and webhook deliveries are near-real-time. Email, Slack, and Teams delivery depend on the destination service but are typically seconds behind the event. Yes — toggle **Enabled** off on the channel's page. Its alert-type selections are preserved, and turning it back on resumes delivery. Both are released progressively. If they aren't in your sidebar yet, they haven't been enabled for your organization — contact support to ask about availability. **Alert Channels** additionally requires an admin role. Check three things: the channel is **Enabled**, the alert type you expect is turned on under **Subscriptions**, and the alert type is one your organization actually receives. **Test** exercises the transport, not your subscriptions, so it succeeds even when no alert type is selected. ## In this section See what's driving the MCP server tooling changed alert. Require human approval before an agent's tool call runs.