InsideDM answers your customers on Instagram and WhatsApp, sells from your catalogue, and follows up after the sale. Doing that means handling two very different sets of people’s data: yours, and your customers’. This page explains what we hold, why, for how long, who else sees it, and how any of it gets deleted.
It is written to be read rather than survived. Where a number exists, we give the number. Where something is a limitation rather than a promise, we say so.
The people who message your business are your contacts, not ours. We hold their data on your instruction, never message them for our own purposes, and never sell it — to anyone, at any price.
We use AI models to write replies. We do not use your conversations to train, fine-tune or improve any model — ours or anyone else's — in raw, aggregated or derived form.
Every table in our database that holds something about a person is listed in a registry with a recorded decision about what erasure does to it. The build fails if someone adds a table and doesn't decide.
Including the parts we don't control. WhatsApp messages pass through Meta's servers outside India before they ever reach us, and no provider in this market can change that.
Nearly every privacy policy in this market describes website visitors and goes quiet about the customers whose messages actually flow through the product. This one starts there.
InsideDM sits between a business and its customers, so we handle two categories of personal data under two different legal roles. Which one you are decides which half of this page applies to you, and who you go to when you want something changed or deleted.
| If you are… | Our role | Who decides what happens to your data |
|---|---|---|
| A business using InsideDM, and the people on your team | Data fiduciary / controller | We do. This page describes it, and you can reach us at the address in section 14. |
| Someone who messaged a business on Instagram or WhatsApp | Data processor, acting on that business's instruction | The business you messaged. We hold your data for them, do only what they configure, and delete it when they say so — or when you ask. |
| A visitor to insidedm.in | Data fiduciary / controller | We do, though there is little to decide. See section 11. |
Where we act as processor, the business sets the purposes and we follow them. We do not decide what a business asks its customers, we do not build a profile of anyone for our own use, and we do not move data between businesses. Each business’s data is stored separately from every other business’s — a hard requirement of Meta’s Platform Terms for technology providers, and one that also rules out anything built by pooling conversations across our customers.
Itemised, by where it comes from. Nothing here is a category invented to sound thorough — each row is data the product actually stores.
| Data | Why we have it |
|---|---|
| Name, work email, password | To create your account and sign you in. |
| Business name, category, website | To set up your workspace and teach the assistant about your business. |
| Team members you invite, and their roles | So the right people see the right parts of the dashboard. |
| Billing details and payment history | To charge you. Card details go to our payment provider, never to us — see below. |
| Support messages you send us | To answer them. |
| Log data: IP address, browser, timestamps, pages used | Security, debugging, and knowing which features get used. |
Received through Meta’s Instagram Platform APIs under permissions you grant during setup. You can revoke them at any time in your Instagram settings, which stops the flow immediately.
| Data | Why we have it |
|---|---|
| Your professional account's ID, username and profile | To connect the account and reply as you. |
| The content of direct messages, comments and story replies — text, media, reactions and button taps | This is the product. The assistant reads the message to answer it, and the thread is kept so the next reply has context and you can read the history. |
| Each customer's Instagram-scoped ID and username, and their profile picture and display name | To know who is talking to you and show a recognisable thread. Instagram-scoped IDs are specific to your account — they are not a person's global Instagram identity. |
| Delivery and read status of messages we send | To show you whether a reply landed. |
| Data | Why we have it |
|---|---|
| Your WhatsApp Business account and phone number IDs | To send and receive on your number. |
| The content of messages to and from your customers, including media | To answer them, and to keep the thread readable. |
| Your customer's phone number and WhatsApp profile name | To identify the conversation and, where you have consent, to message them again. |
| Which template you sent, when, and whether it was delivered, read or failed | Billing, deliverability, and the campaign reporting in your dashboard. |
| Opt-ins and opt-outs, recorded per purpose | To decide whether a message may be sent at all. See section 5. |
| Data | Why we have it |
|---|---|
| Your catalogue: titles, descriptions, prices, variants, stock, images | So the assistant sells what you actually stock rather than inventing it. |
| Orders and their status, with the customer name, email, phone and address attached | To answer “where is my order”, to confirm and follow up on a sale, and to attribute revenue to the conversation that produced it. |
| Payment events: amount, currency, status, timestamp, reference | To know an order is paid, and to reconcile your billing. |
| Public pages of your website, if you ask us to read it | To learn your policies, delivery areas and FAQs so the assistant answers correctly. We read only what any visitor could. |
An exhaustive list. If a use isn't here, we are not permitted to do it — Meta's and Shopify's terms both make this page the boundary of our lawful use, not a description of it.
Where the law asks us to name a legal basis: for your account and billing data we rely on performance of our contract with you, and for security and product improvement, our legitimate interests. For your customers’ data we act on your documented instruction as processor — and the lawful basis for collecting it in the first place, including consent to be messaged, is yours to establish. Section 5 describes the machinery we give you for that.
The section most policies in this market leave out entirely, or answer in one sentence naming no vendor and no number.
We use large language models for inferenceonly: the model is asked a question and returns an answer. To generate a reply we send it the customer’s message, the recent conversation, and the relevant slice of your catalogue and knowledge base. Nothing is sent to a model vendor beyond what the table below describes.
| Where AI is used | What is sent | To whom | Trains on your data |
|---|---|---|---|
| Writing replies to customers | The message, recent thread, catalogue and knowledge extracts | OpenAI (United States) | No |
| Finding the right answer in your knowledge base | Short text passages, converted to embeddings | OpenAI (United States) | No |
| Reading your website when you connect it | Public page content only — no customer data | OpenAI (United States) | No |
| Diagnosing why the assistant answered as it did | Traces of an agent run, which include message content | Langfuse (United States) | No |
Automated replies identify themselves as automated at the start of a conversation, and again when a chat moves between the assistant and a human — because Meta requires it, and because pretending otherwise is a bad way to treat someone. You can take over any conversation at any time.
AI output can be wrong, and output that reads as confident because it is specific can still be materially inaccurate. It is a drafting tool, not an oracle. Do not rely on it for decisions with legal, financial, medical or safety consequences, and do not present it as reviewed by a person when it wasn’t. We do not use AI to make automated decisions producing legal or similarly significant effects for anyone.
Consent to hear that your order shipped is not consent to receive offers. We keep those apart in the database, not just in the copy.
Under WhatsApp’s Business Messaging Policy you may only message someone who gave you their number and opted in, and the opt-in has to cover the kind of message you want to send. InsideDM enforces that rather than trusting it: consent is stored per person, per channel and per purpose, and a send with no matching consent is refused.
| Purpose | What it permits | What it never permits |
|---|---|---|
| Marketing | Campaigns, offers, win-backs. | — |
| Order updates | Confirmed, ready, dispatched, delivery coordination — granted when a customer moves their own order to WhatsApp. | Marketing. Moving your order to WhatsApp is not an opt-in to be sold to. |
| Loyalty programme | Balance, tier changes, expiry warnings, reward unlocks. | Weekend offers. Someone who wants to know their points expire has not asked for promotions. |
| Loyalty payment matching | Linking a payment identifier to a member. Authorises processing, not messaging. | Sending anything at all. |
Opt-outs are honoured whether they arrive through InsideDM or anywhere else — including someone replying “stop”, or blocking the business on WhatsApp. As the business you are responsible for obtaining valid consent before you message anyone and for keeping the record of it. We give you the machinery and enforce it, but we are not the party who obtained it.
The full list, with what each one does. Every vendor here is contractually barred from using the data for its own purposes.
| Who | What they do | What reaches them |
|---|---|---|
| Meta (Instagram & WhatsApp) | The channels themselves — every message travels through them | Message content, phone numbers, account identifiers |
| Google Cloud (asia-south1, Mumbai) | Runs the application | Everything, in transit and in memory |
| Supabase | Managed PostgreSQL — the primary database, and sign-in | Everything we store |
| OpenAI | Language-model inference and embeddings | Message content, catalogue and knowledge extracts |
| Langfuse | Tracing, so we can diagnose why the assistant replied as it did | Agent traces, which include message content |
| Razorpay / Cashfree | Payment processing, whichever you connect | Order amounts and payer contact details. Card data goes to them directly, never through us. |
| Shopify | Catalogue and order sync, if you connect a store | We read from Shopify; we send them no customer data |
| Resend | Sends notification emails, if you enable them | Email addresses and the notification text |
| Cloudflare | DNS, CDN and protection for the website | Network-level request data |
A vendor only appears in your stack if you use the feature it serves. Never connect a store and Shopify receives nothing; never enable email notifications and Resend is never called.
Beyond this list we disclose personal data only where the law requires it, or to protect against fraud, abuse or a threat to someone’s safety. If we are served with a legal demand for a business’s data we will tell that business before responding, unless we are legally prohibited from doing so. If InsideDM is ever acquired or merged, data moves with the business and this notice continues to apply until you are told otherwise.
Including the part we don't control, which no provider in this market does.
Our application runs in Google Cloud’s asia-south1 region in Mumbai. Our database is hosted by Supabase in the region configured for our project.
Some of our vendors — OpenAI, Langfuse, Cloudflare — process data outside India. Those countries may not have equivalent data protection law and, in some cases, may be less protective. Where transfers are subject to European or UK law we rely on the European Commission’s Standard Contractual Clauses and the UK Addendum. Wherever it is processed, we protect it as described here.
Actual windows. The pattern across this market is precise numbers for marketing cookies and silence about message archives; this is the reverse.
| What | How long | Then what |
|---|---|---|
| Conversations and messages | While your account is active | Deleted when you delete the contact or conversation, when you disconnect the channel, or when your account closes. |
| Detailed agent traces (why the assistant answered as it did) | 90 days | Pruned automatically by a scheduled job. |
| Contacts, profiles and consent records | While your account is active | Erased on request. Opt-out suppression records survive, and only those — see section 5. |
| Orders and payment events | As long as tax and accounting law requires | Identifying details stripped on erasure; the amount and date remain as an anonymous business record. |
| Your account and billing records | While your account is active, then as tax law requires | Deleted. |
| Security and application logs | As long as we need them for security and debugging, and for any period Indian law requires | Rotated out automatically. CERT-In's directions set a floor here, so this is one window the law lengthens rather than shortens. |
| Encrypted backups | Until they age out of their own rotation | A deletion removes the record from live systems straight away, but backups are point-in-time and still hold the older copy until they expire. For anything held under a per-person key — phone numbers, payment identifiers — this doesn't matter: erasure destroys the key, so the value is unreadable in the backups too, immediately. |
When you close your account or disconnect a channel we delete the personal data we held for you, except where we are legally required to keep something — in which case we keep only that, and only while the requirement lasts. Where you connected Shopify, an uninstall or a customer-redaction request from Shopify is acted on within the 30 days their platform requires.
Erasure fails by omission, and omission is invisible — a successful-looking erasure that quietly left data behind. Here is the machinery that stops that.
Every table in our database that holds something about a person is listed in a registry, and each carries a recorded decision about what erasure does to it: delete the row, strip the identifying columns, replace the identifier with one that resolves to nobody, or deliberately keep it. A test walks the database schema against that registry, so a new table holding personal data fails our build until somebody has decided, in writing, what erasing a person means for it. Deciding to keep something is allowed. Deciding nothing is not.
Some records must keep existing without keeping the person. Phone numbers and payment identifiers that need to be matched later are encrypted under a key belonging to that one person, held apart from the records referencing them. Erasure destroys that key, which destroys every value under it at once, while the surrounding records keep an identifier that now resolves to nobody. There is no configuration in which those values are stored unencrypted — the system refuses to start rather than fall back to plain text.
Every one of these routes, with the exact wording to send us and what to expect back, is on one page: Delete your data.
You can ask us to show you the personal data we hold about you, correct it if it is wrong, complete it if it is partial, update it, and erase it. You can withdraw consent as easily as you gave it. You can ask for a copy in a portable form, ask us to restrict or stop a particular use, and nominate someone to exercise these rights if you cannot. You can complain to us, and escalate if we don’t resolve it.
Some of these come from the GDPR and UK GDPR, where those apply to you. The rest come from India’s Digital Personal Data Protection Act, 2023 — whose substantive obligations commence in May 2027. We don’t propose to wait: the rights above are available now, and we would rather build the habit early than discover in 2027 that we can’t honour them.
We will not charge you more, or give you a worse service, because you exercised any of these rights.
To make a request, write to privacy@insidedm.in. We may need to verify who you are first — mainly so we don’t hand your data to someone claiming to be you. We acknowledge within 24 hours and complete the request within 30 days. If we can’t do what you asked, we tell you which rule prevents it and what we did instead, rather than going quiet.
InsideDM is a tool for businesses and is not intended for anyone under 18. We don’t knowingly create accounts for children, and wedon’t use anyone’s data for behavioural advertising or build profiles of anyone — which the DPDP Act prohibits for children specifically, and which we don’t do for anyone. The one qualification is the analytics cookie described in “Cookies and the website” above, which Microsoft may use for its own advertising; that is Microsoft’s processing, not ours, and it is why we say it there rather than leaving it implied here.
If a business uses InsideDM to talk to customers who may be children, that business is responsible for the consent the law requires, including verifiable parental consent where it applies. If you believe a child’s data has reached us without that consent, tell us and we will delete it.
The date at the top of this page is the date it last changed. When a change materially affects how we handle your data, we tell account holders by email or in the dashboard before it takes effect — rather than updating the page and relying on you to re-read it. Because Meta’s and Shopify’s terms make this notice the limit of what we may do with your data, we update it before shipping something new, not after.
For anything about this notice or your data, write to privacy@insidedm.in. For everything else, support@insidedm.in.
As required by the Information Technology Rules and, from May 2027, the Digital Personal Data Protection Act, 2023, a named officer is responsible for complaints about how we handle personal data. If you are unhappy with how we’ve dealt with your data or your request, write to them directly.
The full procedure — what to include, what happens at each stage, and where to appeal — is on our Grievance Redressal page.
If our Grievance Officer’s answer doesn’t satisfy you, you have somewhere else to go. Under the Information Technology Rules you may appeal to a Grievance Appellate Committee within 30 days of our decision. Once the Digital Personal Data Protection Act commences in May 2027 you will also be able to complain to the Data Protection Board of India. And if the GDPR applies to you, you may complain to your local supervisory authority at any time.