{"id":3108,"date":"2026-10-23T08:37:25","date_gmt":"2026-10-23T03:07:25","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=3108"},"modified":"2026-10-23T08:37:28","modified_gmt":"2026-10-23T03:07:28","slug":"messaging-data-retention-erasure-sms-whatsapp-rcs-telegram","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/messaging-data-retention-erasure-sms-whatsapp-rcs-telegram\/","title":{"rendered":"Data Retention and Erasure for SMS, WhatsApp, RCS and Telegram: Deleting a Person Without Breaking Opt-Outs"},"content":{"rendered":"\n

A working design for retention and right-to-erasure in a messaging stack: what you can delete at the provider by API, what only a written request removes, how to keep opt-outs working after you erase someone, and how to prove all of it without keeping the data you just deleted.<\/p>\n\n\n\n

\"Abstract<\/a>
Erasure removes the person, not the proof: a few keyed tokens survive so opt-outs keep working.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h1>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. What the Law Asks of a Messaging System<\/a><\/li>\n\n\n\n
  4. Where Personal Data Lives in a Messaging Stack<\/a><\/li>\n\n\n\n
  5. What You Can Delete at the Provider by API<\/a><\/li>\n\n\n\n
  6. What Only a Request Can Remove<\/a><\/li>\n\n\n\n
  7. Filing Processor Erasure Through the Support Ticket API<\/a><\/li>\n\n\n\n
  8. The Retention Schedule as Data<\/a><\/li>\n\n\n\n
  9. Erase, Redact or Pseudonymise<\/a><\/li>\n\n\n\n
  10. The Suppression Paradox<\/a><\/li>\n\n\n\n
  11. Consent Evidence After Erasure<\/a><\/li>\n\n\n\n
  12. The Erasure Request Data Model<\/a><\/li>\n\n\n\n
  13. Finding a Person’s Contacts Without a Search Endpoint<\/a><\/li>\n\n\n\n
  14. The Erasure Worker, Step by Step<\/a><\/li>\n\n\n\n
  15. Data That Arrives After Erasure<\/a><\/li>\n\n\n\n
  16. Retention Jobs You Can Trust<\/a><\/li>\n\n\n\n
  17. Legal Holds and Disputes<\/a><\/li>\n\n\n\n
  18. Proving It Happened<\/a><\/li>\n\n\n\n
  19. Decision Matrix<\/a><\/li>\n\n\n\n
  20. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  21. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    Erasing someone from a messaging system is three different jobs, and most teams only do the first one.<\/p>\n\n\n\n

    The first job is your own database: message bodies, recipient numbers, delivery reports, inbound replies, click logs. You control all of it, so you can delete, redact or pseudonymise on a schedule.<\/p>\n\n\n\n

    The second job is the provider side you can reach by API. On SMSGatewayCenter<\/strong> that means contact rows (SMSApi\/contact\/delete<\/code>), pending scheduled bookings (SMSApi\/schedule\/delete<\/code>), uploaded WhatsApp media (WAApi\/media<\/code> with a mediaId<\/code>), groups and smart links. Each of those deletes needs a read-back afterwards, because a success message only tells you the call was accepted.<\/p>\n\n\n\n

    The third job is everything the provider holds that has no delete endpoint: delivery report rows, inbox rows, activity logs, credit history. Under India’s DPDP Act a Data Fiduciary has to “cause its Data Processor to erase” data it shared, so you need a written request. The Support Ticket API (SMSApi\/support\/create<\/code>) lets you file and track that request from code. Put transaction IDs in the ticket, never phone numbers, because tickets can’t be deleted by API either.<\/p>\n\n\n\n

    The part that trips people up: you can’t erase the fact that someone opted out. If you delete the number, the next import puts them straight back on your list. So keep a keyed hash (HMAC-SHA256) of the normalised number in your suppression table, check every send against it, and erase everything else.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n