There is no single legal number of days you must keep WhatsApp chat logs in India. You keep a conversation for as long as a dispute, a tax record or a platform audit could still need it, and you delete everything past that on a written schedule — because data you no longer hold is data you cannot leak, cannot be asked to produce, and do not have to defend.
That sentence is the whole policy. The hard part is that most Indian businesses running the WhatsApp Business API have never written the schedule down, so chat history, customer phone numbers, uploaded KYC photos and exported CSVs sit in five places at once with nobody owning the delete button. When a customer exercises an erasure right, or a Meta review asks for consent proof, or a laptop with a downloaded export goes missing, the absence of a retention policy is what turns a small event into a long one.
This guide is the operational version: what to keep, how long, where the hidden copies live, and what a deletion request actually has to reach. It assumes you already have consent collected properly — if not, start with WhatsApp DPDP opt-in compliance first, because retention rules applied to data you never had permission to hold do not fix anything.
Why "delete it all quickly" is the wrong instinct
The reflex after reading any privacy law is to purge aggressively. That backfires in India for a specific reason: several of the records you would delete are the same records that protect you.
A customer disputes a charge nine months later. A Meta template appeal asks how the contact opted in. A GST officer asks for the order trail behind an invoice. A consumer complaint arrives and your defence is the message where the customer confirmed the address. In each case the evidence is a WhatsApp conversation, and if your purge job deleted it at ninety days you now argue from memory.
So retention is not a race to zero. It is three buckets: records you must keep because something else compels it, records you keep because a realistic dispute window has not closed, and everything else, which should go on a clock. Most chat volume falls in the third bucket, and that is where the savings and the risk reduction both live.
The retention table that actually gets used
Below is the shape most Indian API senders converge on. Treat the durations as a starting position to confirm with your CA and your counsel against the operative statute and the current rules — the reasoning column is the part that transfers, the numbers are the part you tune.
| What you hold | Typical retention | Why that length |
|---|---|---|
| Opt-in record (who, when, exact wording, channel) | Life of the relationship, plus a buffer after opt-out | This is your defence in a Meta review or a complaint. Deleting it deletes your proof. |
| Order, payment and invoice conversations | Aligned to your books-of-account retention | Tax and audit trails outlive the chat. Confirm the operative period with your CA. |
| Support conversations with no transaction | 6–12 months | Long enough for a repeat complaint, short enough to stop indefinite accumulation. |
| Marketing broadcast send logs | 12–24 months | Needed to prove you honoured opt-outs and to answer "why did I get this". |
| KYC / ID images sent by customers | Shortest possible — purge after verification | Highest-harm data you hold. Keep the verification result, not the photograph. |
| Raw webhook payloads and delivery logs | 30–90 days | Operational debugging only. Nothing downstream depends on them past a quarter. |
| CSV exports and ad-hoc downloads | Days, not months | Uncontrolled copies on laptops and shared drives. These cause most real incidents. |
Two lines in that table do most of the work. Purge ID images early — a verification outcome ("PAN matched, 14 Aug 2026") carries the business value with almost none of the harm. And put exports on a short clock, because the spreadsheet somebody mailed themselves is the copy nobody remembers when a deletion request arrives.
Where the copies hide
A retention policy that only cleans the primary database is theatre. On a typical Indian WhatsApp API stack the same conversation exists in more places than the team expects:
- Your platform database — messages, contacts, conversation threads. The copy everyone remembers.
- Media storage — images, PDFs and voice notes, usually on object storage, often with no lifecycle rule attached.
- Your CRM or ERP — because you synced conversation summaries into it and then forgot the sync existed.
- Database backups — the awkward one. A backup taken before a deletion still contains the deleted rows until that backup itself expires.
- Exports and reports — CSVs, monthly decks, anything a human downloaded.
- Agent devices — screenshots taken to escalate an issue on an internal group.
Backups deserve a written position rather than a pretence. The honest, defensible stance is: deletions are applied to live systems immediately, and backup copies age out on a fixed cycle rather than being surgically edited. Say that in your policy, keep the backup cycle short enough to be credible, and make sure the cycle is real — a thirty-day backup retention that nobody ever tested is not a cycle, it is a hope. If you are building that side out, the same discipline appears in CERT-In and DPDP breach notification, where "which systems held the data" is the first question you get asked.
Get the DPDP WhatsApp checklist
A founder-led WhatsApp reply with the DPDP consent + audit-log checklist for WhatsApp Business messaging. India-hosted. No spam.
What a deletion request has to actually reach
When a customer asks you to delete their data, the answer is not one DELETE statement. Split the request the way an auditor would.
| Request reaches | Action | Note |
|---|---|---|
| Marketing lists and future broadcasts | Remove immediately, permanently | Non-negotiable. This is the part the customer will re-test. |
| Support chat history with no transaction | Delete | Nothing else depends on it. |
| Media they uploaded | Delete from object storage, not only the DB row | Deleting the pointer leaves the file. |
| Transaction and invoice records | Retain, and say so | Retained under a separate obligation, not under consent. Explain that plainly. |
| Opt-out record itself | Keep | You need proof that they opted out, or you cannot prove you stopped. |
| Backups | Age out on the normal cycle | State the cycle length in your reply. |
The reply that works is short and specific: what was deleted, what was retained, under which reason, and when the backup copies expire. A vague "we have deleted your data" invites a follow-up you cannot answer when the invoice trail obviously still exists.
Retention is a configuration, not a project
The teams that keep this working do not run quarterly cleanup drives. They set it once in three places and let it run:
- A scheduled purge job on the conversation tables, driven by a per-category age rule, running nightly and logging counts.
- A lifecycle rule on media storage so uploaded files expire without anybody remembering them.
- An export register — a one-line log of who downloaded what and when, with a standing instruction to delete the local copy after use.
The third one looks trivial and prevents the most incidents. Exports are the only copies with no automatic expiry and no owner.
What sits on Meta's side versus yours
A common assumption is that WhatsApp holds the archive for you. Plan as if it does not. The platform's own retention of message content and media is short and outside your control, and media in particular can become undownloadable far sooner than teams expect — which is exactly why a serious setup downloads inbound media on receipt rather than fetching it later.
The practical split: Meta holds the transport, you hold the record. Delivery receipts, template status and quality signals live with the platform. Conversation content, consent evidence and customer identity live with you, which means the retention obligation is also yours. Confirm the current platform-side behaviour against Meta's operative documentation rather than assuming last year's window still applies.
What this costs
Almost nothing, which is why the excuse for skipping it is weak. Retention work is engineering time, not licence spend. On RichAutomate the messaging itself is usage-only — ₹0 setup, ₹0 monthly, and you pay per message: ₹0.10 per message on Client Pay (plus ₹0.20 when a 24-hour window opens), or ₹1.20 marketing and ₹0.30 utility on SaaS Pay. Storing three years of chat history rather than one changes your object-storage bill by a few hundred rupees a month at typical SME volumes. The real cost of over-retention is never the storage; it is the size of the disclosure when something goes wrong. Current rates are on the pricing page.
A 30-day path to a policy that exists
- Week 1 — inventory. List every place a conversation lands, including the CRM sync nobody documented and the shared drive full of exports.
- Week 2 — classify. Put each data class in one of the three buckets: compelled, dispute-window, everything else.
- Week 3 — automate. Nightly purge job, media lifecycle rule, export register. Log the counts so you can prove it ran.
- Week 4 — write it down. One page: what you keep, how long, why, and how someone requests deletion. Date it, own it, review it yearly.
Pair it with the wider checklist in the DPDP Act WhatsApp compliance checklist, and if you are also preparing for a platform review, the record set described in opt-in evidence for a Meta audit is the one thing your purge job must never touch.
The one mistake worth avoiding
Do not let a purge job and a consent-proof requirement collide. Teams write a clean "delete conversations older than 180 days" rule, ship it, and six months later cannot answer a template appeal because the opt-in message was inside a conversation the job deleted. Store the consent record as its own row, outside the conversation table, with its own retention rule. Then the chat can expire on schedule and the proof survives.
That separation is the single highest-value change in this article. Everything else is scheduling.