**Notifications** covers everything Authdog sends on your behalf: _"Email events, providers, delivery channels, and templates for your application."_

![Notifications events](/content/console/notifications.events.png)

Two different things live here, and it helps to keep them apart:

- **Email to your users** — verification, invitations, magic links. Configured under Providers, Configuration, and Emails.
- **Alerts to your team** — audit and security events forwarded to Slack or a SIEM. Configured under Channels.

The rail also carries a **RELATED** block linking to [Branding](/docs/console/branding), Localization, and [Domains](/docs/console/domains).

## Events

_"Delivery, open, and bounce activity for emails sent from this application."_ A time-range selector (default: Last 30 days) sits in the header.

This is your deliverability view. Bounces concentrated on one domain usually mean a DNS or reputation problem at the receiving end; a flat zero when you expect traffic means the provider is not actually connected.

## Providers

_"Choose how emails are delivered. One provider is active at a time; the managed provider is used until you connect your own."_ Sub-tabs split **Email** from **SMS**.

| Provider | Setup |
|----------|-------|
| **Authdog (managed)** | Sends through Authdog's shared infrastructure. No setup required — the default. |
| **Custom SMTP** | Your own SMTP server: host, port, and credentials. |
| **Resend** | An API key from your Resend account. |
| **SendGrid** | A SendGrid API key, for high-volume sending. |
| **Amazon SES** | AWS access credentials and a region. |
| **Postmark** | Postmark server tokens. |

The active provider is marked **In use**; the rest show **Connect**.

> **Tip**
>
> The managed provider is fine for development and for low volume. Connect your
> own before launch: sending from your own domain is what gets your emails past
> spam filters, and it puts the delivery logs in a system you already monitor.

Store provider credentials as environment secrets in [Vault](/docs/console/vault) rather than pasting them into more than one place.

## Configuration

_"Defaults applied to every email sent from this application."_

**Sender identity** — _"The name and address recipients see in their inbox"_ — takes a **From name**, **From address**, and **Reply-to address**.

**Delivery tracking** — _"Collect engagement metrics for emails sent from this application"_ — has two toggles:

| Toggle | Effect |
|--------|--------|
| **Track opens** | Inserts a tracking pixel to record when emails are opened. |
| **Track clicks** | Rewrites links to record when recipients click through. |

Both feed the Events tab. Both also have privacy implications — a tracking pixel is a third-party-style beacon in your users' inboxes — so enable them deliberately rather than by default.

## Channels

_"Configure where notifications are sent."_ Click **"Add Channel"** to create one; the table lists Name, Type, Default Channel, Recipients, Triggers, and Status.

Channels forward audit and security events to systems your team already watches:

| Type | Destination |
|------|-------------|
| **Webhook** | Any HTTPS endpoint you own. |
| **Slack** | A Slack channel via incoming webhook. |
| **Datadog** | Datadog Events API. |
| **Sysdig** | Sysdig Events API. |
| **Splunk** | Splunk HTTP Event Collector (HEC). |
| **Sumo Logic** | Sumo Logic collector. |

Each channel picks its **triggers** — which event types it cares about — so a Slack channel can carry only critical security signals while a SIEM channel takes everything.

Delivery is retried durably: a destination that is briefly unreachable does not lose events.

## Emails

The template editor. Pick a template — **Invitation**, verification, magic link, and so on — and edit it with a rich-text editor. **"Open preview"** renders it, and each template has an enable toggle (for example _"Send the invitation template when inviting a new user"_).

Per template you can set the **Sender name**, **Reply-to email**, and **Subject**, then compose the **Email body** with formatting controls (bold, italic, bullet list, heading, paragraph).

### Variables

_"Customize the selected template with reusable variables in `{{VAR_NAME}}` format."_ The **Variables** panel manages the tokens available in the editor and their preview values. Each has an **Insert** button that drops it at the cursor.

The invitation template ships with:

| Token | Resolves to |
|-------|------------|
| `{{USER_NAME}}` | The recipient's name |
| `{{APP_NAME}}` | Your application name |
| `{{INVITE_URL}}` | The accept-invitation link |
| `{{SENDER_NAME}}` | Who the invitation is from |

**"Add variable"** defines your own. **"Reset draft"** discards unsaved edits; **"Save changes"** publishes.

> **Caution**
>
> Removing `{{INVITE_URL}}` from the invitation body leaves recipients with no
> way to accept. Use **Open preview** before saving any template that carries an
> action link.

## Related

| Read | To learn how to |
|------|-----------------|
| [Audit](/docs/console/audit) | Find the event types a channel can subscribe to |
| [Lidar](/docs/console/lidar) | Generate the security signals worth alerting on |
| [Branding](/docs/console/branding) | Match email styling to the hosted pages |
| [Vault](/docs/console/vault) | Store provider credentials as environment secrets |
| [Events & webhooks](/docs/events-webhooks) | Consume forwarded events in your own systems |
| [Email providers](/docs/email-providers) | Provider-specific setup details |
