Preference center & compliance

Every channel you send on comes with an obligation: the subscriber gets to leave. ReachBell handles that for you — a hosted preference center, automatic STOP handling on the phone channels, and a send-time consent gate that quietly skips anyone who has opted out. You don't scrub lists by hand, and you don't ship a campaign that reaches someone who told you to stop.

The hosted preference center

ReachBell hosts a preference page so you don't have to build one. The subscriber lands on it from a "manage preferences" or "unsubscribe" link in your message, makes their choices, and ReachBell records them.

There's no login. The link carries a signed token that identifies the subscriber on its own:

https://api.reachbell.com/prefs/<token>

The token is an HMAC-SHA256 signature minted when the message is sent. It proves ownership without a password, can't be forged into another subscriber's token, and stops verifying the moment the subscriber is deleted — at which point the page reads "this link has expired" rather than leaking whether the id ever existed.

Always include a preferences/unsubscribe link. ReachBell mints the token and exposes it in email and push payloads, but it's on you to surface the link in your template. An email with no way out is the fastest route to a spam complaint — and to your sending domain's reputation tanking.

What the subscriber can change

Control	Effect
Channels	Turn `push`, `email`, `sms`, or `whatsapp` on or off individually.
Categories	Opt out of specific topics (e.g. "product updates") while staying subscribed overall.
Pause	Snooze everything until a date — a softer alternative to a full unsubscribe.
Phone opt-out	A hard opt-out across both SMS and WhatsApp at once.
Unsubscribe all	One button that deactivates the subscriber and marks email `unsubscribed`.

Behind the page, three public endpoints back the flow — handy if you ever build your own UI on top of the same token:

Method & path	What it does
`GET /prefs/:token`	Returns the subscriber's email, phone status, and current preferences.
`POST /prefs/:token`	Updates channels, categories, pause date, or phone opt-out.
`POST /prefs/:token/unsubscribe`	Global unsubscribe — the same as "unsubscribe all".

Per-channel opt-out

Opting out of one channel never touches the others. The state lives on the subscriber in two places:

preferences.channels — a { push, email, sms, whatsapp } object of booleans. This is the fine-grained per-channel switch the preference center toggles, and the one the send path reads.
phoneStatus — active or opted_out. A single hard flag covering both phone channels (SMS and WhatsApp), set by a STOP reply or the phone opt-out toggle.
emailStatus — active, bounced, complained, or unsubscribed. Email gets its own status because providers report bounces and complaints that ReachBell records here automatically.

So a subscriber can keep push, drop email, and silence SMS — and each campaign respects exactly that.

STOP / keyword handling (SMS & WhatsApp)

Inbound replies on the phone channels are processed automatically. When a subscriber texts a stop word, ReachBell flips phoneStatus to opted_out for that phone number; a start word flips it back to active. The match is case-insensitive and ignores punctuation, so Stop. and STOP both count.

Stop words (opt out):

STOP   STOPALL   UNSUBSCRIBE   CANCEL   END   QUIT   OPTOUT   REVOKE

Start words (opt back in):

START   UNSTOP   SUBSCRIBE   OPTIN   YES   RESUME

Anything else is a no-op. ReachBell does not send a confirmation auto-reply — your provider or BSP typically sends the carrier-mandated acknowledgement, and on WhatsApp an unsolicited reply would itself need an open service window.

For ReachBell Cloud the inbound webhook is already wired. If you self-host or connect your own Meta app, point WhatsApp at the webhook so STOP replies reach this handler — see WhatsApp → Receiving messages. The same opt-out shows up in the preference center, so the two stay in sync.

An inbound STOP and the preference-center "phone opt-out" toggle set the same flag. There's one source of truth for phone consent, however the subscriber reached it.

Email unsubscribe

Today, email opt-out runs through the hosted preference center: the unsubscribe link in your email lands on /prefs/:token, and choosing to unsubscribe sets emailStatus to unsubscribed and stamps the time. Bounces and complaints reported by the email provider also land in emailStatus automatically, so a hard bounce or a "mark as spam" takes the address out of rotation without any action from you.

RFC 8058 one-click unsubscribe

RFC 8058 defines the List-Unsubscribe and List-Unsubscribe-Post headers that let Gmail and Apple Mail render a native "Unsubscribe" button at the top of a message — a one-click opt-out that bulk senders are now expected to support.

Heads up: ReachBell does not yet inject these headers on outgoing email — opt-out is via the in-body preference link described above. RFC 8058 header support is on the roadmap. Until it ships, keep a clearly visible unsubscribe link in every marketing email; it's both good practice and required by most mailbox providers' bulk-sender rules.

Recording an opt-out only matters if sends respect it. ReachBell enforces consent at dispatch, so a suppressed subscriber is skipped — you don't have to filter them out yourself.

Push campaigns dispatch only to active subscribers; dead tokens (a 410/404 from the push service) are marked inactive and drop out of future sends.
Email campaigns match only subscribers whose emailStatus is active and whose preferences.channels.email isn't false.
SMS & WhatsApp — both broadcasts and transactional sends check the recipient first. Broadcasts filter the audience to phoneStatus: active with the channel enabled; a transactional send to an opted-out subscriber is rejected with a clear error rather than delivered.

The consent gate keys off the subscriber. A transactional SMS or WhatsApp sent to a raw to number (rather than an identified subscriber) has no preference record to check — so reserve direct-number sends for genuine one-offs like OTPs, and route everything else through an identified subscriber.