You sent a briefing. You want to know whether it arrived, and whether anyone did anything with it. RelayLink will answer that, and it will not dress a scanner up as a reader.
The lines you get
On the package — and in an export, the same list — a sender sees:
- Sent. The package exists.
- Notification accepted or failed. The mail provider took it, or did not.
- Delivered or bounced. The provider later said so. Deferred and complained stay off this trail; they are not the same claim.
- Pulled. Their assistant fetched the briefing. That is the honest "an agent on their side has it" — shown to you only when they have not turned it off.
- Acknowledged. Someone pressed the button that means they read it.
- Replied. A reply package landed.
thread_status answers with one of three things for a thread awaiting someone: they have seen it, not seen yet, or read receipts not shared. The third is the recipient's own choice, not a fact about your message — a person can turn read receipts off entirely, or leave them on generally and turn them off for you specifically, the way an iPhone's read receipts work per conversation. Withheld and not-yet-pulled read identically on purpose: if withholding ever rendered as "not seen yet" until the moment a reply proved otherwise, you would eventually notice the pattern, which is a subtler way of RelayLink lying to you than showing the fetch outright. Acknowledging and replying are unaffected either way, because they are things the recipient chose to do rather than a passive trace of an assistant doing its job — they always show.
If a webhook or a preview could act on the briefing without a pull being recorded at all, the one honest answer would go quiet for exactly the accounts using them. That is why outbound webhooks carry an envelope and never the note.
The lines you do not get
A fetched link. /p/{token} is requested by mail security scanners and link previewers before any human sees the message. Recording the fetch is useful. Showing it as evidence of reading puts the false signal back on the screen people consult to answer "did they get it."
A portal view. Opening the briefing in their account is the same class of fact the other way around: a page rendered, not a person saying they read it. Acknowledging is still the line that means that.
The attempt that always has a sequel. An "we tried to send mail" event is followed by accepted or failed. Showing all three makes one send look like three things.
What this is for
The product exists to keep "who said what, and whether it was seen" honest. A read receipt that fires on a previewer is a lie with a timestamp. A missing line on a fetch is the feature.
If you need a machine to notice that a package arrived, register a webhook. It gets the same envelope honesty: ids, sender, topic, not the briefing.