Webhooks & Notifications
How the platform tells people and machines that something happened — email and in-app notifications plus outbound webhooks.
Two audiences, two channels
When something meaningful happens inside RapidValue — a joiner arrives, an access request is submitted, a review is due, a leaver is finalised — the platform can announce it. Announcements go to two very different audiences, and each has its own channel:
- People are reached through notifications — email and an in-app inbox (the bell). The content is a human-readable message, translated into the four supported locales.
- Machines are reached through webhooks — an outbound message posted to an endpoint your own systems control, so an external system can react to the event.
They share only the word "event". The recipients are different objects (a person versus a machine endpoint), so the two channels are configured in different places, and this page describes both.
| Notifications | Webhooks | |
|---|---|---|
| Recipient | People — an identity, a role, an address (or a Teams/Slack channel, see below) | A machine endpoint — a URL your systems own |
| Delivery | Email and the in-app inbox | An outbound HTTP POST, signed |
| Managed under | Notifications & Email | Environment & connections |
| Purpose | Tell a person to act or be aware | Let an external system react automatically |
Notifications: templates, inbox, and delivery
The notification side has four concerns.
Templates. For each event and each locale, there is an editable message template — subject and body. An admin can edit a template, auto-translate it to the four locales, preview the rendered output, and send a test to a real address before enabling it. Built-in templates ship curated but are tenant-overridable, so the wording can match your organisation's voice.
The in-app inbox. Every user has a bell with an unseen count and a list of their own notifications. Items can be marked seen (or all-seen at once) and deep-link back to the surface they came from, so a notification is a shortcut to the work, not a dead end.
Delivery. An admin chooses how email is actually sent:
smtp— real delivery through a configured mail server. Choosing it without a mail-server host is refused, and so is clearing the host while it is chosen.log_only— messages are logged, not sent (safe for non-production).redirect— everything is redirected to one address (safe for staging).disabled— nothing is sent.
Full mail-server setup (host, port, encryption, authentication with the password held in the vault, from and reply-to addresses) plus a test-connection probe let an admin confirm the mail path works before going live. A sent-message log with a per-message failure reason (connection refused, authentication failed, recipient rejected, bounce, rate-limited, template error) plus a delivery-health signal (which says so when the tenant sends through the platform's own mail relay instead of reading "not configured") make it possible to prove a message was delivered — or diagnose why it was not — and retry after a fix.
Rules for generated passwords. When a platform-created account gets a generated initial password, a Rules tab on the Notifications page decides who receives it (the person, their manager, a fixed address or an address on the person's record) and with which template. Redirect mode applies to these mails as well, and changing the redirect address needs the credential-delivery configure permission and is recorded in the configuration change log.
Digests and chat channels. The same page has a Digests tab, where an admin schedules recurring summary mails addressed to a role or to one person, and a Channels tab for Microsoft Teams and Slack. A channel carries only the approver notifications (an approval waiting, a review assigned, a review due soon). Each card has one link to the decision page and no approve or reject buttons. The channel URL is treated as a credential: it is stored in the vault and never shown again after saving.
💡 Tip
The
log_onlyandredirectmodes exist precisely so a test or staging tenant never emails real people. Useredirectto funnel every message to a single mailbox you can watch.
Webhooks: outbound event delivery to your systems
A webhook endpoint is a URL you register, together with a signing secret and the set of events you want it to receive. When a subscribed event fires, the platform posts a JSON message to that URL. The receiving system verifies the X-RapidValue-Signature header (sha256= followed by an HMAC-SHA256 of the raw request body, keyed with your signing secret) to confirm the message came from RapidValue, then reacts however it needs to — open a ticket, kick off an integration flow, update a downstream record. The X-RapidValue-Event header names the event, and the body carries the event, tenant, time, subject, actor and event data.
What you get:
- Multiple endpoints per tenant, each with its own event filter, so different downstream systems subscribe to different events. An endpoint with no events selected receives all of them.
- A test-send to confirm an endpoint is reachable and its signature is being verified correctly. Test deliveries are marked as tests and do not count toward delivery health.
- A delivery log, so you can see what was sent, the HTTP status, and a structured failure reason (DNS error, connection refused, timeout, TLS error, 4xx, 5xx). A failed delivery can be retried; the retry re-sends the stored body and is logged as a new attempt.
- A delivery-health signal over the last 24 hours: delivered and failed counts, failure percentage and the last failure reason.
A signing secret that cannot be resolved from the vault makes the delivery fail; the platform never sends an unsigned message instead. Endpoint URLs must be http or https and may not point at loopback, link-local, cloud-metadata or private addresses; this is checked when you save and again when the message is sent, and redirects are not followed. A failing endpoint never blocks the event or the other endpoints, and the platform does not retry automatically.
Webhook endpoints live on the Environment & connections surface, the technical tenant-setup home, alongside single sign-on, agents, branding, and API credentials.
What events fire
Notifications are driven by a catalog of trigger events — things like an access request being submitted, approved, or rejected; a manager change; a joiner, mover, or leaver (JML — joiner/mover/leaver) transition; a review coming due; an advisor finding. A template is bound to an event, and when that event fires the matching template renders and delivers to the resolved recipients.
Both channels now subscribe to one canonical event vocabulary. The older names stay valid: a template or a webhook subscription stored under a legacy name still matches, and a webhook saved with a legacy name is stored under its canonical key. The webhook form offers the catalog and ready-made presets that tick a set of events.
💡 Tip
Think of it as one question — "when X happens, who and what should be told?" — answered along two axes: a person gets an email or inbox item, and a machine gets a webhook. Designing the two together avoids wiring the same event twice under two different names.
Where this sits in the surface
Because the recipients are different objects, the editing homes stay split by persona: email templates, rules, digests, channels and mail-server setup live on Notifications & Email; webhook endpoints live on Environment & connections. The Routing tab on Notifications & Email is the read-first view across both: one row per event showing its template state, its subscribed webhook endpoints and a delivery-health signal, while the configuration itself still happens in each channel's home.