You want something outside RelayLink to notice when a package arrives — a small agent on a laptop, a workflow runner, a queue. Outbound webhooks are that signal: a signed POST to a URL you registered, whenever mail lands for you.
Where this host offers them, they live on /account/webhooks.
Envelope, not content
The payload is enough to decide whether to wake up and fetch:
- Event type and a delivery id (the same bytes on every retry, so you can dedupe)
- Package id and thread id
- Sender name and address, topic, time
- Whether it is a reply
- This host's
/mcpaddress
It does not carry the note, the TL;DR, or the ask.
Two reasons.
"Have they seen it" comes from a pull. thread_status answers that from get_package. If the webhook carried the briefing, a consumer could act on the content and never make that call, and the sender's honest answer would go quiet for exactly the accounts using this.
A leaked signing secret should not publish prose. An envelope tells an agent to go fetch a package it has to authenticate for. Prose in the payload would put chosen words in front of that agent with only the secret as a gate.
When it fires
The webhook is queued in the same place as the notification email — after the block check. Blocking someone from an email therefore closes this channel too. There is no separate webhook block.
Delivery is at-least-once. Retries send identical bytes and the same delivery id. That is ordinary for webhooks (they can carry an id); email cannot.
The POST is not put through the app's generic HTTP retries. Those would retry underneath the outbox's own retries, and a receiver would see attempts RelayLink never recorded.
Secrets
The signing secret is stored as issued, because the server signs with it. Treat it like a password. It is shown once, when you create the receiver.
The URL is treated like a secret the other way: webhook paths often carry a token, so account notices name only the host, and logs name only the subscription id. Neither the secret nor its hint is in an account export.
Not the inbound email webhook
"Webhook" elsewhere in RelayLink means inbound mail being delivered to the app — how a reply by ordinary email reaches a thread. That is infrastructure. Outbound webhooks are a control you turn on per account. Do not configure one when you meant the other.
When the page says this host does not offer it
Some deployments do not enable outbound webhooks. The account page says that, rather than pretending the route is missing. /docs omits the section. Describing a capability a host does not have is how setup guides go stale.
If the page offers registration, create a receiver, store the signing secret outside any chat transcript, and point it at something that will call /mcp with your credential when an envelope arrives. What's new and the inbox is still how an assistant inside a conversation learns. The webhook is how something outside one does.