Recipient links

These are the only routes of the product a recipient reaches directly, without a key. You never call them — you make sure your template carries them.
URLMethodWho opens itAnswer
/api/o/{token}GETThe recipient's mail client, on openA 1×1 transparent GIF
/api/t/{token}GETThe recipient, on a clickA 302 to the real destination
/api/unsubscribe/{token}POSTThe mail client (RFC 8058 one-click)Neutral, whatever the token is worth
/unsubscribe/{token}pageThe recipient, from the email footerThe unsubscribe page
/subscribe/confirm/{token}pageA new contact, from the opt-in emailThe confirmation page

Double opt-in confirmation — /subscribe/confirm/{token}

A contact created through the double opt-in flow lands in pending and receives a confirmation mail. Opening the link moves it to subscribed. Until then it is in the audience but receives nothing.
There is no public "subscribe" endpoint. A contact enters an audience through POST /api/v1/lists/{listId}/contacts, with an API key — see the Audience API. Confirmation is the only public half of the flow, and it is a page, not an API. Nobody can push contacts into your lists from the outside.

What this means for the API

The status of a contact is the meeting point between these public links and the API, and the API deliberately gives way:
  • PATCH /api/v1/contacts/{contactId} ignores a status sent in the body. Subscription state changes through explicit acts only.
  • An upsert never silently resurrects an unsubscribed contact.
  • A recipient who unsubscribed from their mail client is unsubscribed for good; only POST /api/v1/contacts/{contactId}/resubscribe can undo it, and never for a bounced address.
The unsubscribe token of a contact is never exposed by /api/v1. It exists only inside the emails that were sent to that contact.