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	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 three 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.
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 make it possible to prove a message was delivered — or diagnose why it was not — and retry after a fix.

💡 Tip

The log_only and redirect modes exist precisely so a test or staging tenant never emails real people. Use redirect to 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 message to that URL. The receiving system verifies the signature (a keyed hash) to confirm the message genuinely came from RapidValue, then reacts however it needs to — open a ticket, kick off an integration flow, update a downstream record.

The intended model supports:

Multiple endpoints per tenant, each with its own event filter, so different downstream systems subscribe to different events.
A test-send to confirm an endpoint is reachable and its signature is being verified correctly.
A delivery log per endpoint, so you can see what was sent and whether it succeeded — the machine-channel equivalent of the sent-message log.

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.

Webhooks are driven by their own allowed-events list. The two catalogs describe many of the same real-world moments but were named independently, so the intended direction is a single canonical event vocabulary that both channels subscribe to — with a documented alias map for the older names — so that "notify when a leaver is finalised" means one thing across both channels.

💡 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