You want both the person and their self-hosted agent to notice a package. Sending the same kind of notification twice is not the answer: people and machines need different signals, different security boundaries, and different evidence.
RelayLink email and outbound webhooks can coexist because they do different jobs.
Email is the human notice
The notification email is written for a person. It identifies the sender and topic, gives the recipient a RelayLink link, and provides a reply path. A person can use it without operating a public callback service.
Email is useful when the recipient is away from an assistant, when their agent is not running, or when they want to read and reply in an ordinary human channel. It also gives an account holder a path back to the portal or their connected assistant.
But email delivery is not reading. A provider accepting a message says nothing about whether it reached the inbox view a person uses. A package-link request says even less: mail security scanners, previewers, and corporate filters routinely fetch links before a human touches them.
RelayLink therefore never treats a link fetch as read evidence.
A webhook is the machine trigger
An outbound webhook is a signed POST to a public HTTPS receiver registered at /account/webhooks. It is meant to start machine work without waiting for a person to notice an email.
The package.received body is an envelope. It carries the delivery, package, and thread ids; sender name and email; topic; sent time; reply state; and mcp_url. It does not carry the note, TL;DR, ask, or context brief.
The receiver verifies the signature, deduplicates the delivery id, queues work, and returns 2xx. A worker then authenticates separately through MCP and calls get_package.
This is a trigger, not a second copy of the briefing.
Why both can be enabled
For an account with an active receiver, the webhook can start the agent while email tells the person that something arrived. If the agent handles the package promptly, the person may never need the email. If the receiver is down, the email remains a separate way to notice and act.
The implementation keeps that independence explicit. A failure while queueing webhooks must not prevent the notification email. A later timeout or non-2xx response from the receiver also does not retract or suppress the email.
The block check comes before both notification paths. If the recipient has blocked the sender, RelayLink queues no webhook for that package and suppresses the notification rather than using one channel to bypass the other.
Neither transport is a read receipt
A webhook 2xx proves that a machine accepted an envelope. It does not prove that the worker ran, that MCP authentication succeeded, or that an assistant fetched the package.
An email provider response proves that the provider accepted or rejected the submission. It does not prove a human opened it. Fetching the link is also not evidence because automated systems do that.
RelayLink keeps stronger events separate:
get_packagerecords that the recipient's assistant pulled the package through MCP.- An acknowledgement records a deliberate action by the recipient.
- A reply records an answer.
That distinction is why acknowledging is not opening, and why a successful webhook is not added to the sender's trail as “their agent was notified.”
Choose by audience, not by speed alone
Use email when the person is the audience and should have a durable notice and reply path. Use a webhook when a self-hosted system should begin an automated workflow. Enable both when human awareness and machine timing both matter.
Do not build a rule that treats one as a fallback read receipt for the other. If the webhook fails, inspect /account/webhooks and let the agent reconcile with check_inbox. If the person wants the sender to know they saw the package, they can acknowledge it.
The outbound webhook overview explains the envelope boundary. What the sender sees after a send explains which delivery events are evidence and which are intentionally absent.