Opt-out and suppression
STOP, HELP and START are three different branches. Configuring only the receipt endpoint is the mistake that makes the whole chain fail silently.
Read this article →What the platform holds about a message, what it deliberately does not, and where the data subject relationship actually sits.
The message log stores metadata: the time, the destination number, the tenant, the provider, the sender identity, the normalised status, the provider message ID and the raw error code. Credentials are stored encrypted, and suppression records hold the judgement plus the minimum audit detail needed to explain it.
Message bodies are not persisted. This is a deliberate compliance decision: a body is a real conversation, and retaining it would create retention, export and deletion obligations that metadata does not — for a benefit that amounts to one more readable column.
Match on the destination number in international format.
Read the metadata rows: when, which channel, which sender, what status.
If the number opted out, the suppression entry is the audit trail for that decision.
Content, consent evidence and the commercial relationship are yours, not the platform’s.
The relationship with the recipient is yours, so the request is answered by you. The platform processes the metadata on your instruction and does not decide who may be messaged — nothing on this page is legal advice about how your obligations apply.
STOP, HELP and START are three different branches. Configuring only the receipt endpoint is the mistake that makes the whole chain fail silently.
Read this article →The platform keeps metadata about your messages, not their content. Here is exactly what that means for your own records.
Read this article →Connect a provider, issue a key, send your first message — and meet the two defaults that quietly cost money if you miss them.
Read this article →