Unsubscribe & tracking
The public engagement endpoints — one-click unsubscribe, the hosted preference center, and signed open and click tracking.
Four endpoints are reached directly by recipients and their mail clients, not by your code. They are documented here because their behavior shapes what lands in your webhooks and your suppression list.
Every one of them trusts an HMAC signature minted at send time — never the caller. There is no API key involved, because the person clicking a link in an email doesn't have one.
| Path | Methods | Purpose |
|---|---|---|
/o/{id} | GET | Open-tracking pixel |
/c/{id} | GET | Click redirect |
/u | GET, POST | One-click unsubscribe |
/p | GET, POST | Hosted preference center |
One-click unsubscribe
/u implements RFC 8058 and is
served on both verbs for a reason:
GET— a human clicked the unsubscribe link in the message body.POST— the mail client's own one-click button (Gmail, Apple Mail) acting on theList-Unsubscribe-Postheader, with no human in the loop.
Supporting both is a deliverability requirement for bulk senders, not a nicety. The link is signed and tenant-scoped, and transactional and marketing streams get distinct tokens, so unsubscribing from a newsletter does not silence a password reset.
An unsubscribe adds the address to your
suppression list, after which sends to it
return 200 with { "status": "suppressed" } rather than being delivered.
That is a success response, not an error — check status, not just the
status code.
Hosted preference center
/p lets a recipient make per-topic choices instead of leaving entirely.
The preference token is a narrower credential
/p tokens carry a distinct prefs: scope, so a preference-center link
can never be replayed as a one-click global unsubscribe — the two
signatures verify against different scopes. If you build your own
preference UI, do not route it through the /u token: that would widen a
deliberately narrow credential into a global opt-out.
Open tracking
When enabled, a 1×1 pixel pointing at /o/{message_id} is injected into the
HTML before send. A fetch of that pixel records an open and fires the
matching webhook event.
Open tracking is best-effort by nature: a client that blocks remote images never loads the pixel, so an absent open is not evidence the mail went unread. Treat opens as a trend signal across many messages, never as a fact about one.
Click tracking
When enabled, links in the HTML body are rewritten to /c/{message_id} with
the original destination carried in a signed parameter. The endpoint verifies
the signature, records the click, and redirects to the original URL.
Because the target is part of the signed payload, a tampered redirect fails verification rather than forwarding the recipient somewhere you never linked.
What this means for your HTML
Both features modify the HTML you send — a pixel appended, hrefs rewritten.
If you diff sent output against your template, or your tests assert on exact
markup, either account for the rewriting or send with tracking off.
See Webhook events for the event payloads these endpoints produce.