Publishing events
Downstream systems need to know when a governed record changes — when a golden record is updated, when records merge, when a privacy request is fulfilled. Webhooks deliver those notifications.
How it works
Webhook subscriptions, each with the destination and the event types it is subscribed to.
Register an endpoint, subscribe it to the event types you care about, and the platform posts to it when they occur. Each delivery is recorded with its outcome, so you can see what was sent and what happened to it.
Event types are discoverable
The set of available event types is served by the platform rather than documented as a static list here. Query it and subscribe to what you find — a list written into documentation would drift from what the platform actually emits.
Outbound request protection
A webhook is an outbound HTTP request to an address you supply, which makes it a potential vector for reaching internal infrastructure. Destinations are validated before any request is made, at every entry point — creating a webhook, updating one, testing one, and delivering to one.
Validation pins the resolved address, so a destination cannot pass validation and then resolve somewhere else at delivery time. A rejected destination is recorded as a security event.
Delivery semantics
Be aware of the current behaviour when designing a consumer:
- Delivery is at-most-once. There is no automatic retry; a failed delivery is recorded and stays failed until it is re-sent explicitly.
- Deliveries have a short timeout. A slow consumer is treated as a failure.
- Delivery failures never affect the originating operation. The change has already committed.
- Events about webhooks are never themselves delivered, so a webhook subscribing to its own event types cannot cause a feedback loop.
With at-most-once delivery, a consumer that treats webhooks as a complete change feed will eventually miss something. Treat them as a low-latency notification and reconcile periodically against the API for correctness.
Secrets
A webhook carries a shared secret so the receiver can verify the caller. Note that the secret is delivered in the request body for the receiver to compare, rather than used to compute a signature header. If you need signature-based verification, treat that as a gap to raise rather than assuming it is present.
Testing
A webhook can be test-fired without waiting for a real event, which is the fastest way to confirm the destination is reachable and your consumer parses what it receives.
Next
Last verified against commit 315eb047 (2026-08-03)