Account Notifications
Workboard can keep the normal in-app notification inbox and also forward matching notifications to external channels for the signed-in user.
You can configure this under:
- Open Settings
- Open Account
- Open Notifications
Available channels
Users can forward matching notifications through:
EmailntfyGotifyCustom webhook
These settings are personal to the signed-in account. They do not change notification routing for other users in the workspace.
How it works
Workboard already stores in-app notifications in the notification inbox. Account notification delivery adds a separate preference layer on top of that behavior.
Important rules:
- the in-app inbox remains the source of truth
- outbound delivery only applies to newly created notifications
- historical notifications are not replayed
- delivery failures do not block notification creation
- delivery can be scoped by workspace and, optionally, by selected projects
Global channels
The Notifications page includes separate connection cards for:
EmailGotifyntfyCustom webhook
Configure each channel once at the account level, then decide which workspaces are allowed to use it.
Email delivery uses the signed-in account email address.
Requirements:
- the user must have an email on the account
- SMTP must be configured on the server
ntfy
ntfy requires:
- a server URL
- a topic
- optionally, a bearer token
Gotify
Gotify requires:
- a server URL
- an application token (bearer token)
Setup notes:
- create an application in your Gotify server before connecting Workboard
- paste the base server URL, for example
https://gotify.example.com - no extra topic or path is required because Workboard sends directly to the Gotify message API using the application token
- if your Gotify server uses a custom port or TLS, include that in the server URL
Custom webhook
Custom webhook requires:
- a destination URL
- optionally, a signing secret
When a signing secret is configured, Workboard sends an X-Workboard-Signature header containing the HMAC-SHA256 hex digest of the raw JSON body.
Workspace delivery rules
Below the global channel cards, Workboard shows workspace delivery rules.
Each workspace rule can:
- be active or paused
- enable or disable
Email,Gotify,ntfy, andCustom webhook - apply to
All projects - or apply to
Selected projectsonly
This lets a user receive notifications from one workspace in ntfy, another by email, and ignore the rest.
Supported notification sources
V1 forwards the same notification types that currently create inbox notifications in Workboard.
That includes:
task_createdworkspace_createdtask_status_changedtask_assignee_changedtime_entry_created
If Workboard cannot resolve a notification to a workspace or project context, that notification stays inbox-only.
Reachability and security
For security, Workboard validates outbound HTTP destinations before saving or sending.
Private or non-routable destinations are rejected, including examples like:
localhost127.0.0.110.x.x.x172.16.x.xto172.31.x.x192.168.x.x
This applies to:
ntfyserver URLsGotifyserver URLs- custom webhook URLs
If you are using a self-hosted ntfy instance, Gotify instance, or webhook receiver, it must be reachable from the API with an accepted public or routable hostname.
If your receiver only exists on a private network, set KANEO_ALLOW_PRIVATE_WEBHOOK_DESTINATIONS=true on the API to bypass this guard. It is off by default, the http/https protocol requirement still applies, and enabling it re-opens the SSRF surface the check protects against. Only turn it on for a trusted, isolated deployment.
Troubleshooting
Notifications show in Workboard but are not delivered
Check that:
- the global channel is configured and enabled
- a workspace rule exists for the notification workspace
- the workspace rule is active
- the channel is enabled on that workspace rule
- the project is included when using
Selected projects
Email is enabled but nothing is sent
Check that:
- SMTP is configured correctly
- the signed-in user has an email address
- the server can reach the SMTP provider
ntfy, Gotify, or webhook save fails
Check that:
- the URL is valid
- the destination is reachable from the API server
- the hostname does not resolve to a blocked local or private address