Messaging Acceptable Use Policy

Version: 2026-08-18
Effective date: 18 August 2026

This Messaging Acceptable Use Policy (“Policy”) applies to every use of SMSFlow messaging, campaign, inbox, template, API, webhook, integration, automation, and related functionality. It is incorporated into the SMSFlow Terms of Service. It is not a separate privacy policy or alternative terms of service.

1. Purpose and responsibility

SMSFlow helps businesses communicate using SMS, WhatsApp, and related channels. Messaging must be expected, lawful, relevant, secure, and respectful. Customers remain responsible for their recipients, lawful basis, consent, content, timing, configuration, users, integrations, and sector obligations.

SMSFlow may enforce stricter safeguards than the legal minimum to protect recipients, customers, telecommunications providers, Meta/WhatsApp, SMSFlow’s app and reputation, and the integrity of the platform.

2. Laws, codes, and provider rules

Customers must comply with all applicable requirements, including:

  • the Protection of Personal Information Act 4 of 2013 (“POPIA”);
  • the Consumer Protection Act 68 of 2008 and its direct-marketing regulations;
  • the Electronic Communications and Transactions Act 25 of 2002;
  • applicable ICASA requirements and the WASPA Code of Conduct;
  • the WhatsApp Business Terms, WhatsApp Business Messaging Policy, WhatsApp Messaging Guidelines, Meta technical documentation, and commerce rules where applicable;
  • advertising, consumer, competition, intellectual-property, cybersecurity, employment, financial-services, healthcare, education, gambling, alcohol, age, and other sector or country rules; and
  • Customer contracts, notices, and promises to recipients.

Where rules conflict, the most protective applicable restriction should be followed unless law requires otherwise.

3. Consent and recipient expectations

Before business-initiated messaging, Customer must have the recipient’s number and the required channel-appropriate opt-in or other lawful basis. Evidence must be capable of showing:

  • recipient or number;
  • date and time;
  • source and collection method;
  • channel;
  • scope and category, including Service, Utility, Authentication, and Marketing where relevant;
  • notice wording or version;
  • collection context and expected sender; and
  • Customer or responsible party.

Consent must be voluntary, specific, informed, and capable of withdrawal where required. Customer must not:

  • use purchased, rented, scraped, harvested, randomly generated, or unlawfully shared lists;
  • bundle unrelated Marketing consent into a service request;
  • infer Marketing permission from a prior purchase, general relationship, inbound enquiry, or consent to another channel unless law and provider rules clearly permit it;
  • misrepresent the sender, purpose, frequency, value, or category of messages; or
  • continue messaging when consent evidence is missing, stale, disputed, or outside its scope.

WhatsApp recipients should expect the categories of messages they receive. Separate category-specific opt-ins are strongly preferred and may be required by SMSFlow.

4. Opt-out, objection, and suppression

Customers must provide a clear, easy, and free way to opt out where required and must honour requests received on or off the messaging channel.

SMSFlow may recognise common SMS opt-out expressions such as STOP, OPT OUT, END, CANCEL, UNSUBSCRIBE, and QUIT, together with contextually equivalent requests. A recipient must not be forced to use exact wording where the intention is clear.

Suppression is applied according to the request’s expressed scope. Relevant restrictions may include:

  • all-channel business-initiated suppression;
  • channel-specific suppression;
  • Marketing or other category suppression;
  • a legal or do-not-contact restriction;
  • a WhatsApp account or recipient block;
  • an explicit conversation block; and
  • a Customer or SMSFlow platform-integrity block.

The most protective applicable state wins. An import, administrator action, retry, automation, new campaign, or inbound message must not silently remove suppression. A new inbound request may permit a contextual human service reply where lawful and within the WhatsApp customer-service window, without reviving proactive Marketing permission.

Customers must keep external systems and SMSFlow suppression state consistent. They may not bypass suppression by changing a number format, user, API key, tenant, channel, template, integration, or sender.

5. Direct-marketing times and frequency

Unless a legally valid exception or recipient agreement applies, direct marketing must not be timed for prohibited periods, including:

  • Sundays and South African public holidays;
  • Saturdays before 09:00 or after 13:00; and
  • other days between 20:00 and 08:00 the following day.

Customer must consider the recipient’s local time and applicable jurisdiction. Scheduling a send during an allowed period does not excuse deliberate evasion or excessive frequency.

Customers must use reasonable frequency limits, avoid message bursts that surprise or harass recipients, and pause Marketing where complaint, block, quality, or engagement evidence shows elevated risk. SMSFlow may apply platform limits, quiet hours, rate shaping, or campaign review.

6. SMS requirements

SMS direct marketing must identify the sender where required, include an effective opt-out instruction, honour WASPA and applicable do-not-contact restrictions, and maintain required consent and dispatch evidence. Transactional or service messages must not be disguised Marketing.

Message length, encoding, concatenation, route, sender, destination, and carrier filtering may affect parts, delivery, and price. Customers must review previews and estimates and must not use altered characters, URL tricks, rotating senders, or other measures to evade filters.

7. WhatsApp requirements

7.1 Business profile and assets

Customer must own or be authorised to administer connected Meta business assets and must keep the WhatsApp business profile, display name, website, email, telephone, and support information accurate. Customer must not impersonate or misrepresent another business, affiliation, or activity.

7.2 Initiated messages and templates

WhatsApp business-initiated conversations must use an approved Message Template where required. A template may be used only for its approved category, language, purpose, variables, and intended recipient context. Approval does not guarantee that a particular send is lawful or policy-compliant.

Customer must not manipulate variables, media, buttons, URLs, or surrounding automation so that the delivered content differs materially from the approved template. SMSFlow may rehydrate provider-critical template data server-side and reject stale, paused, rejected, disabled, deleted, or miscategorised templates.

7.3 Customer-service window

Customer may send a free-form reply only within the applicable 24-hour customer-service window measured from the recipient’s last message, subject to consent, suppression, content, and other controls. Outside that window, an approved template is required. A browser or client-side state cannot override the server-side decision.

7.4 Automation and human escalation

Automation may respond during the customer-service window or send an authorised approved template, but must be transparent where appropriate and provide a prompt, clear, and direct escalation path, such as transfer to an agent, telephone, email, web support, support form, or suitable physical support channel.

Automation must be bounded, idempotent, non-recursive, permission-controlled, and subject to the same consent, suppression, template, quiet-hour, frequency, quality, and financial controls as human messaging. Automated Marketing must remain disabled unless separately enabled under an approved Customer policy with explicit Marketing consent.

7.5 Data protection and prohibited identifiers

Customer must not use WhatsApp data for an unrelated purpose, share one recipient’s chat with another recipient, or request or transmit full payment-card numbers, financial-account numbers, identity-document numbers, or other provider-prohibited sensitive identifiers. Health or other sensitive information may be processed only where law, provider policy, security, and SMSFlow’s written approval permit it.

7.6 Quality and restrictions

Recipients may block or report businesses. Meta may limit messaging where quality is poor or policy is breached. Customer must monitor quality, template, number, WABA, and restriction states and cooperate with remediation. SMSFlow may automatically pause campaigns or automation when quality deteriorates, a restriction applies, or consent/complaint evidence creates risk.

8. Prohibited content and conduct

Customers must not use the Services to:

  • violate law, court order, regulatory direction, industry code, provider terms, or another person’s rights;
  • send spam, unsolicited bulk messages, phishing, scams, fake recruitment, fake prizes, pyramid or fraudulent schemes;
  • deceive, confuse, surprise, coerce, exploit, harass, threaten, shame, or intimidate;
  • impersonate another person or business or misrepresent affiliation, source, approval, price, availability, or outcome;
  • promote hatred, violence, terrorism, organised crime, discrimination, abuse, sexual exploitation, trafficking, or harm;
  • distribute malware, malicious links, credential theft, circumvention tools, or unauthorised surveillance;
  • infringe intellectual property, privacy, confidentiality, publicity, or proprietary rights;
  • intercept or disclose communications without authority;
  • evade opt-outs, rate limits, quality controls, sender registration, templates, feature flags, permissions, billing, or provider enforcement;
  • send content or process data that SMSFlow has not contractually agreed to protect at the required sensitivity; or
  • interfere with, probe, overload, reverse engineer, or compromise the Services or another tenant.

9. Regulated and restricted goods, services, and industries

WhatsApp prohibits or restricts specified organisations, content, goods, and services even where locally licensed. Restrictions may include firearms, alcohol and tobacco, drugs, medical products, endangered species, hazardous goods, currency and certain financial products, gambling, adult services, dating, multi-level marketing, payday lending, debt collection, and other regulated or high-risk activity.

Limited provider exceptions may apply only in specified countries and under strict age, geography, licence, notice, and commerce controls. Customer must obtain SMSFlow’s written approval before using the Services for a regulated vertical and must immediately stop if a licence, country allowance, provider permission, or legal basis expires or changes.

Customers in healthcare, financial services, education, employment, insurance, credit, or other sensitive contexts must complete an appropriate risk and data-protection review. SMSFlow may refuse a use case even if it may be lawful.

10. Authentication and one-time-password messages

Authentication content must be used only for legitimate verification or account-security purposes. Customers must protect codes, limit validity and attempts, avoid exposing sensitive account data, and prevent social-engineering misuse. Authentication templates must not contain unrelated Marketing.

11. Media, links, and files

Customer is responsible for media, documents, URLs, catalogues, and interactive content. Files must be lawfully owned or licensed, accurately described, safe, and appropriate. Customers must not bypass type, size, malware, or access controls. SMSFlow may scan, quarantine, reject, or remove unsafe or unsupported media.

12. APIs, webhooks, and integrations

API and webhook customers must:

  • use only issued credentials and authorised scopes;
  • keep credentials secret and rotate them on suspected compromise;
  • validate signatures and use HTTPS;
  • implement bounded retries, idempotency, rate limits, and duplicate handling;
  • avoid logging secrets or unnecessary personal information;
  • return webhook acknowledgements promptly and process asynchronously where appropriate;
  • protect exported data and customer webhook destinations; and
  • stop calls when a feature, permission, number, template, or recipient is disabled.

Customers may not use retries or alternate endpoints to replay a provider send whose outcome is unknown. They must follow the documented reconciliation or operator-resolution process.

13. Complaints and incident cooperation

Customers must maintain a working support route and promptly investigate recipient complaints, delivery anomalies, opt-out failures, unauthorised messaging, data incidents, and provider restrictions. They must preserve relevant evidence without retaining unnecessary content, apply immediate suppression or pause where needed, and cooperate with SMSFlow, providers, regulators, and affected persons.

Urgent security, child-safety, credible-harm, systemic-spam, or account-compromise reports receive priority and may trigger immediate restriction before investigation is complete.

14. SMSFlow controls

SMSFlow may evaluate authorisation at preview, queueing, scheduled execution, retry, automation execution, and immediately before provider dispatch. Controls may include:

  • tenant, user, role, permission, and feature entitlement;
  • sender, number, WABA, connection, quality, and restriction state;
  • contact identity, consent, suppression, and service window;
  • template identity, revision, category, language, status, and variables;
  • quiet hours, frequency, campaign, automation, and source workflow;
  • content, media, destination, rate, and technical validation;
  • financial readiness and agreed plan limits; and
  • duplicate, idempotency, security, and abuse detection.

Client-side eligibility is explanatory only. SMSFlow may reject or pause a request even if an earlier estimate or preview allowed it, because final state is rechecked.

15. Investigation and enforcement

SMSFlow may investigate suspected breach and may:

  • reject, delay, quarantine, or remove content;
  • suppress a recipient or block a sender, template, number, API key, integration, user, channel, campaign, automation, or tenant;
  • reduce throughput, require evidence or remediation, or disable a feature;
  • preserve and disclose evidence where lawful;
  • recover provider charges or costs caused by Customer breach;
  • notify Customer administrators, recipients, providers, regulators, or law enforcement where required or appropriate; and
  • suspend or terminate Services under the Terms.

A provider request already in flight may complete. Genuine inbound and status callbacks may continue to be received and retained while outbound functionality is disabled to prevent evidence loss and provider retry storms.

16. Appeals and restoration

Customer may submit a documented appeal to [email protected] with the affected tenant, channel, sender, campaign or event, time, lawful basis, consent evidence, remediation, and requested outcome. SMSFlow may require an independent compliance review, revised consent flow, list cleansing, template correction, security remediation, or monitored restart.

Provider restrictions remain subject to provider appeal processes and decisions. SMSFlow cannot guarantee restoration.

17. Changes

SMSFlow may update this Policy to reflect law, provider rules, security, abuse patterns, or product changes. The published Policy will show its version and effective date. Material changes will be notified as required by the Terms or law.