Webhooks: connect Trusted to the systems you already run.

Who benefits

Outgoing webhooks are configured by administrators in Settings → Webhooks.

Overview

Trusted now sends events to an HTTPS endpoint you control. You can subscribe to advocate status changes, request status changes, reference request match changes and asset status changes, filter deliveries down to the statuses you care about, choose a payload format for Slack or Microsoft Teams, send a test before you wait on a real event, and check delivery history when something looks wrong.

Headless advocacy means the proof and the programme data show up wherever your teams already work, rather than in another tab. Trusted stays the system of record for advocacy - advocates, requests, references and assets all live here - and webhooks are the plumbing that pushes that record out to everything else. When something changes in Trusted, we make an HTTPS POST to a URL you own, and your side decides what to do with it: update a CRM record, kick off an automation, post to Slack, call an internal API.

Outgoing webhooks cover four event families today: advocate status changes, request status changes, reference request match changes and asset status changes. The advocate one is the most used, and the pattern is identical across all four - pick the event, point it at a URL, and Trusted does the rest.

Status filters keep the noise down. Leave them empty and you get every matching change; select MEMBER and your system only hears about advocates who become programme members. Nothing else creates a delivery for that webhook.

You can pick how the payload arrives. Default sends generic Trusted JSON, Slack formats the event as Block Kit so it lands readably in a channel, and Microsoft Teams sends an Adaptive Card. There is also an optional token, appended to your URL as a query parameter, so your receiver can check that a request really came from us.

Two things make live running easier. Test sends a synthetic event to your URL on demand and reports back the HTTP status and latency, which is what you want after creating a webhook or changing your receiving code. Delivery history records real deliveries over time - attempt time, outcome, response status, latency - so you can tell a Trusted problem from a problem further down the chain. Failed deliveries retry automatically, so build your receiver to be idempotent and ignore an event id it has already handled.

Incoming webhooks work the same way in reverse, letting another system push data into Trusted. Between the two, plus the API and the MCP server, advocacy stops being a destination your team has to visit and becomes a service the rest of your stack can call.

Setting up an outgoing webhook

1. 1
   Prepare your endpoint

   You'll need an HTTPS URL your team controls, publicly reachable, accepting POST with a JSON body and returning a 200. If processing takes a while, accept the request and handle it asynchronously.
2. 2
   Open Settings → Webhooks

   Sign in as an administrator and go to Settings, then Webhooks. Everything is added, edited and deleted from here.
3. 3
   Add a webhook

   Select Add webhook, give it a name your team will recognise, and paste in the HTTPS URL Trusted should call.
4. 4
   Choose the event and filters

   Pick the event type - advocate status, request status, reference request match or asset status - and optionally narrow it to the statuses you care about. Empty means everything.
5. 5
   Set a format and token

   Default JSON, Slack Block Kit or Microsoft Teams Adaptive Card. Add a token if you want your receiver to authenticate requests, and store it safely: we only show a masked value once it's saved.
6. 6
   Test, then watch delivery history

   Run a test to confirm connectivity, then use delivery history to check real events are landing and to investigate anything that fails.