mirror of
https://github.com/goauthentik/authentik
synced 2026-04-28 02:18:11 +02:00
6ed5cb5249
* website/integrations: rename "Create with Provider" to "New Application" The application list page now uses a split-button labeled "New Application" instead of the old "Create with Provider" dropdown. Update all 113 integration guides to match. * website/docs: update flow, stage, and policy button labels - "Create" → "New Flow", "New Stage", "New Policy" for trigger buttons - "Finish" → "Create Flow", "Create Stage", "Create Policy" for submit - "Create and bind stage" → "New Stage" / "Bind Existing Stage" - "Create" (binding submit) → "Create Stage Binding" * website/docs: update provider button labels - "Create" → "New Provider" for trigger buttons - "Create with Provider" → "New Application" in RAC docs - "Create" → "New Property Mapping", "New RAC Endpoint", "New Prompt" for related entity creation * website/docs: update directory button labels - "Create" → "New Source" for federation/social login pages - "Create" → "New Role", submit → "Create Role" - "Create" → "New Invitation" - Policy binding submit → "Create Policy Binding" * website/docs: update endpoint device and system management button labels - "Create" → "New Endpoint Connector", "New Enrollment Token", "New Device Access Group", "New Flow" - Submit → "Create Device Access Group" - "Create" → "New Notification Rule", "New Notification Transport" - Binding submit → "Create Policy Binding" * Reorganize policy documentation * website/docs: address policy docs review feedback * post-rebase * website/docs: Reorganize policy documentation -- Revisions (#21601) * apply suggestions * Fix escaped. * Fix whitespace. * Update button label. * Fix phrasing. * Fix phrasing. * Clean up stragglers. * Format. --------- Co-authored-by: Dominic R <dominic@sdko.org>
85 lines
3.2 KiB
Markdown
85 lines
3.2 KiB
Markdown
---
|
||
title: Notification Transports
|
||
sidebar_label: Notification Transports
|
||
---
|
||
|
||
To receive notifications about events you must first [create a notification transport](#create-a-notification-transport), and then define a notification rule with a bound policy. For more information, see the [Workflow overview](./notifications.md#workflow-overview).
|
||
|
||
## Notification transport modes
|
||
|
||
Notifications can be sent to users via multiple mediums, or _transports_:
|
||
|
||
- Local (in the authentik user interface)
|
||
- Email
|
||
- Webhook (generic)
|
||
- Webhook (Slack/Discord)
|
||
|
||
### Local
|
||
|
||
This notification transport will manifest the notification within the authentik user interface (UI).
|
||
|
||
### Email
|
||
|
||
Select this transport to send event notifications to an email address. Note that by default the [global email configuration](../../install-config/install/docker-compose.mdx#email-configuration-optional-but-recommended) is used.
|
||
|
||
To edit an email address, follow the same instructions as above for configuring the global email during the installation process.
|
||
|
||
### Webhook (generic)
|
||
|
||
This will send a POST request to the given URL with the following contents:
|
||
|
||
```json
|
||
{
|
||
"body": "body of the notification message",
|
||
"severity": "severity level as configured in the trigger",
|
||
// User that the notification was created for, i.e. a member of the group selected in the rule
|
||
"user_email": "notification user's email",
|
||
"user_username": "notification user's username",
|
||
// User that created the event
|
||
"event_user_email": "event user's email",
|
||
"event_user_username": "event user's username"
|
||
}
|
||
```
|
||
|
||
The `Content-Type` header is set to `text/json`.
|
||
|
||
##### Webhook Certificate Authority
|
||
|
||
If the server in the webhook URL doesn’t have a certificate issued by a public certificate authority, you can select a Certificate-Keypair here to validate the server’s certificate. If no keypair is selected, authentik will use the Root certificates from [mkcert.org](https://mkcert.org/).
|
||
|
||
#### Webhook mappings
|
||
|
||
You can use Webhook mappings to configure the request's payload and/or header. These are a type of property mapping that can be applied to the `Webhook Body Mapping` or `Webhook Header Mapping` fields of the webhook notification transport.
|
||
|
||
##### Webhook body example
|
||
|
||
An example of a webhook body mapping that sets a `foo` key with its value set to the body of the notification:
|
||
|
||
```python
|
||
return {
|
||
"foo": request.context['notification'].body,
|
||
}
|
||
```
|
||
|
||
##### Webhook header example
|
||
|
||
An example of a webhook header mapping that sets an authorization key:
|
||
|
||
```python
|
||
return {
|
||
"Authorization": "Bearer <token>"
|
||
}
|
||
```
|
||
|
||
### Webhook (Slack or Discord)
|
||
|
||
This sends a request using the Slack-specific format. This is also compatible with Discord's webhooks by appending `/slack` to the Discord webhook URL.
|
||
|
||
## Create a notification transport
|
||
|
||
1. Log in as an administrator to the authentik Admin interface, and then navigate to **Event > Notification Transports**.
|
||
|
||
2. Click **New Notification Transport** to add a new transport or click the **Edit** icon next to an existing notification transport to modify it.
|
||
|
||
3. Define the **Name** and **Mode** for the notification transport, enter required configuration settings, and then click **Create Notification Transport**.
|