Skip to main content
An opt-out is a customer’s instruction to stop some or all communications from your business. Make that choice easy to express and apply it to the workflows that can contact the customer. Do not require the customer to use one exact keyword before you recognize a clear request to stop.

​
Recognize the request and its scope

Requests can arrive through WhatsApp, a preference page, email, or your support team. WhatsApp’s Business Messaging Policy requires you to honor opt-outs made both on and off WhatsApp. A customer may stop promotional offers while still requesting updates for an active order. Preserve clear category preferences when your system supports them. If the request is broad or ambiguous, do not interpret it as permission for continued campaigns. Do not assume that authentication, utility, or service messages are always exempt from the customer’s stated preference or applicable law.

​
Apply the decision before the next send

A reliable process should:
  1. Record the request and its scope.
  2. Update the relevant unsubscribe or preference record.
  3. Remove the customer from pending audiences and follow-up sequences.
  4. Ensure retries and manual operations use the same decision.
  5. Synchronize the change with connected systems.
Check sends that are already queued. Updating a CRM field does not necessarily remove a message from every downstream queue. A short confirmation can help the customer understand the result, where sending that confirmation is permitted. Do not add a promotion, require a survey, or make the opt-out conditional on another action.

​
Manage opt-outs in YCloud

YCloud provides an unsubscribe list and a rule-based agent workflow for adding unsubscribers. The Unsubscribers API records a customer and channel together. These records are distinct from deleting a customer contact. Confirm which of your sending paths enforce suppression automatically. Do not assume that an opt-out recorded in one campaign also blocks every custom API caller, integration, or separate account.

​
Important API distinction: suppression is not identical across send paths

The current YCloud queued endpoint, POST /v2/whatsapp/messages, supports filterUnsubscribed. It defaults to false. When enabled, an applicable unsubscribe can stop the send and produce RECIPIENT_UNSUBSCRIBED in the message error. That option does not apply to POST /v2/whatsapp/messages/sendDirectly. If your integration uses direct sending, enforce the relevant preference check in your workflow instead of assuming the queued endpoint’s filter protects it. Similarly, the queued endpoint’s filterBlocked is a separate option for your block list; it is not proof of customer consent. Source: YCloud OpenAPI contract. These are API behaviors, not a claim about every console product’s default suppression behavior.

​
Define the handler behind an opt-out button

Meta marketing template labeling the Unsubscribe quick-reply button.

The Unsubscribe button returns a response. Your workflow must record the preference and suppress later offers.

Source: Meta official example. For a Stop offers quick reply:
  1. Recognize the inbound response or configured payload.
  2. Resolve the correct customer and WhatsApp channel.
  3. Record the scope and time of the request.
  4. Add the appropriate suppression.
  5. Prevent pending campaigns and follow-up automations from contacting the customer for that purpose.
  6. Send only a permitted, non-promotional acknowledgement if needed.
A quick-reply label is not an unsubscribe list update by itself. A CRM tag is also insufficient if the sending system never reads it. Test a natural-language request such as “Please don’t send me promotions anymore,” not just STOP. Broad requests such as “Do not contact me again” need broader handling than stopping one campaign.

​
Make the process testable

Use a test customer to check: Also test natural-language requests and the languages your customers use.

​
Resubscribe only after a new decision

A customer can change their mind, but a manual deletion from the unsubscribe list is not evidence of renewed consent. Record the new opt-in and its scope before removing the relevant suppression. Keep enough history to distinguish a genuine resubscription from an accidental import or administrator action. See Customer opt-in for evidence design.

​
Avoid harmful practices

Do not switch to another business number to continue an unwanted campaign. Do not make stopping messages harder than subscribing. Do not send a new promotional message simply to ask why the customer unsubscribed. Clear opt-out handling protects customer trust and supports message quality.

​
Frequently asked questions

A button is only the interaction surface. Verify that its response records the customer’s preference and stops the relevant Campaign, Journey, Rule-based Agent, and API sends. Test the direct and queued send paths separately; YCloud’s optional queued-send filtering is not a universal guarantee that every API request checks the list.
The agent must be able to record the request with its scope and effective time. Apply it before the next relevant send, including queued or retried messages. Do not require the customer to repeat the request using an exact keyword or button.
No. Understand the scope: stopping offers is different from refusing every contact. Respond to the customer’s current service request using an eligible message and the applicable window, without silently restoring marketing permission or adding a promotion to the reply. Respect a broader no-contact request according to its scope.