Suppression and consent

The list of people who must not be messaged, checked on every send so that nothing — including a workflow — can reach them.

Two different things

Consent is a record that somebody agreed to be contacted on a channel, and where they agreed. Marketing templates require it; a reply inside an open conversation does not, because the customer started it.

Suppression is a record that somebody asked to stop. It outranks everything — an open window, an approved template, a workflow mid-run.

Where it is enforced

On every send, in one place. Every path — a person replying in the dashboard, a workflow sending a template, a conversation opened outbound — goes through the same check.

Why there is no override

Automation is the caller most likely to message somebody who asked not to be, because there is nobody reading the thread first. A second send path that had to remember the rules would eventually forget one, and that failure is a regulatory one rather than a technical one — Meta blocks numbers that generate opt-out reports, and Nigeria's NDPA does not care which of your services sent the message.

Who has opted out

GET /v1/suppressions

Each entry has the handle, when, what triggered it, and a scope. all is an unqualified STOP and blocks every message. marketing means the customer chose to keep utility messages - delivery updates, order confirmations - and only promotions are blocked. Read it before wondering why a workflow reports a refusal rather than a send.

There is no endpoint to add to this list. An opt-out is recorded when the customer's own message arrives, which is the only evidence of it that means anything.

Lifting one

POST /v1/suppressions/resubscribe

{
  "handle": "+2348012345678",
  "reason": "Asked to be re-added by phone, 13 Sept"
}

Owners only. reason is required, and it is not bureaucracy. Removing somebody from a suppression list is the single most consequential thing in this API — it makes a person who asked to be left alone reachable again. The suppression row is deleted, so the only record of the lift is the entry written to the API's log: which handle, which user, and the reason you give. Write it for the person who has to answer for it later.

A customer typing START themselves lifts their own opt-out, and is recorded separately, as their own act rather than a staff member's.

Only on a request you can point to

A customer asking in the shop, or by phone, or in the thread itself. Never because a list looked short.

Workspaces and team →

Members, roles, invitations and API keys.