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."
- Acknowledged. Someone pressed the button that means they read it.
- Replied. A reply package landed.
thread_status answers "have they seen it" from that pull, not from a link fetch. If a webhook or a preview could act on the briefing without that call, 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.