Privacy Policy

Two kinds of people, two different roles#

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.

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.

What we collect#

Itemised, by where it comes from. Nothing here is a category invented to sound thorough — each row is data the product actually stores.

From you, when you sign up and use InsideDM

When you sign in, we record each browser session: the approximate browser family, operating system and device type (desktop, mobile or tablet), and when it was first and last seen. We don't store your IP address or your full browser identifier with it. We record security events for your account — sign-ins and sign-outs, changes to sign-in methods and to where your security codes go, and session revocations — and keep them for 400 days. We send security notifications about these events to your account email.

If you set up security codes, we store the WhatsApp number or email address you choose for them and use it only to send you those one-time codes, before important changes such as a refund, a plan change, a team or connection change, or closing your account. Meta delivers the codes we send on WhatsApp, from InsideDM's own WhatsApp Business account; our email provider, Zoho ZeptoMail, delivers the codes we send by email. We store codes only as keyed digests, never the code itself, and each one expires within minutes. Before you first set up codes we ask you to enter your password again.

If a workspace you belong to sets a sign-in rule requiring security codes, we record each change to that rule as a security event its owners can see, and show them how many members have not set up security codes — never which method anyone chose or where their codes go.

From Instagram, when you connect your account

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.

From WhatsApp, when you connect a business number

From your store and payment provider, if you connect them

From your Meta ad account, if you connect it

If you connect your Meta ad account, we read it with Meta's ads_read permission only: we never create, change or pay for an ad. For each ad a customer came from when they started a chat with you, we keep its name, its ad set and campaign names, its clicks and spend over the last 28 days, and the link Meta gives us to its picture — never a copy of the ad itself, and nothing about the people who saw it. We refresh it every few hours so you can see which ads start conversations and what they cost. Disconnecting the ad account deletes it.

From your own system, if an automation listens to it

If you give an automation its own address, your booking app, billing software or website can tell us about a customer — for example, that their order shipped. From each message we keep only what you chose in that automation: who the customer is (their mobile number, email, Instagram username, WhatsApp user id or your own id for them), their name, and the fields you turned into blanks for your messages. Everything else in the message is dropped as it arrives. If we don't know the customer yet, we add them by their mobile number, and we remember the id your system uses for them so a later message can name them by it. What a message carried is kept with the run it started, for at most 7 days; the customer and what the automation sends them are kept like any other chat (section 8), and erasing the customer removes the id we remembered. A promotion goes only to a customer who agreed to hear from you. A message sent to the automation's test address reaches nobody, adds nobody and is kept only as a test in your automation's activity.

From a staff calendar, if you connect one

If you connect a Google or Microsoft calendar, or add one by an iCal or CalDAV link, and give it to a staff member, we read when each event on it starts and ends and whether it marks them busy — never an event's title, attendees or notes — so bookings are offered only when that person is free. If you allow writing, we add each confirmed booking to their calendar with the service, the attendee's name, the venue, any notes you published for that service and a link to the conversation; a customer's private intake answers are never copied into a calendar. When a customer is erased, we delete the events we added for them, and keep trying until the calendar confirms it. Disconnecting a calendar stops both at once.

From the agents you turn on to sell, take bookings and follow up

Only if you turn them on. Each row is data the product keeps when you do; section 8 says how long, and erasing a customer removes what is theirs.

Why we use it#

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.

• To run the assistant. Read an incoming message, work out what it asks, look up the answer in your catalogue or knowledge base, and write a reply.
• To keep conversations coherent. Hold the thread so the next reply knows what was already said, and so you can read the history and take over at any point.
• To take and track orders, send payment links, and confirm and follow up on a sale.
• To send the campaigns and follow-ups you configure— and to block the ones consent doesn’t allow.
• To show you your own business back to you: which conversations converted, which of your ads started them and what those ads cost, what customers keep asking, which products come up.
• To bill you, including counting the AI and messaging usage your plan charges for.
• To keep the service up and safe: debugging, fraud and abuse prevention, rate limits.
• To meet legal obligations — tax records, and lawful requests we are required to answer.

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.

How AI is used, and what that means for your data#

The section most policies in this market leave out entirely, or answer in one sentence naming no vendor and no number.

What actually happens when the assistant replies

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.

The assistant says that it is one

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, and how opt-outs work#

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.

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.

Who else touches the data#

The full list, with what each one does and the data it receives. Meta conversion reporting also follows Meta's applicable Business Tools Terms.

Most vendors only appear in your stack if you use the feature they serve. Never connect a store and Shopify receives nothing; never connect your own invoicing account and Zoho Invoice never sees a customer of yours. Email is the exception, and we would rather say so than imply otherwise: some messages aren’t optional. Invite a teammate or ask us to reset your password and that email goes through ZeptoMail, because there is no version of those where nothing is sent.

Your own integrations

A workspace owner or administrator can connect a system of their own to InsideDM with an API key or a webhook endpoint. When they do, InsideDM sends that system the customer data the key's scopes permit, and nothing else: contacts.read releases contact names, phone numbers, email addresses and channel identifiers; conversations.read releases who took part, on which channel and when, but not the messages; messages.read releases the text of messages and descriptions of attachments; orders.read releases order and payment status and amounts; shipments.read releases shipment status. contacts.write permits creating phone contacts and changing contact tags and custom fields, and releases current values. A key with only read scopes cannot change data. Webhook notifications carry identifiers only — never message text, contact details or addresses.

A workspace can also send enquiries on to a Google Sheet, HubSpot, Zoho CRM or a webhook of its own. An enquiry goes there only when someone in the workspace approves it, and with only the fields the workspace chose. To reach a Google Sheet or Zoho CRM, someone in the workspace signs in to it and allows InsideDM to add and update records there; we use that access only to write the enquiries the workspace approves into the sheet or CRM it chose, and to remove them again, and — if the workspace also keeps its catalogue in a Google Sheet (section 2) — to read that one sheet; we never read anything else in that account. The credentials for these tools are encrypted and never shown again. We keep a record of what went where, so that when a customer is erased we ask that tool to delete what we sent, and keep asking until it confirms. The workspace can pause a destination at any time.

We never do this unless the workspace sets it up, and its owner or an administrator can revoke a key or turn off an endpoint at any time, which stops the flow at once. The business, not InsideDM, is responsible for the system it connects and for telling its customers about it. Those systems are the business's own processors, not ours, so they are not on the list above and connecting one does not start the 30 days' notice.

Beyond this list we disclose personal data only where the law requires it, to a system the workspace itself has connected under Your own integrations, 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.

Where the data actually sits#

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.

How long we keep things#

Actual windows. The pattern across this market is precise numbers for marketing cookies and silence about message archives; this is the reverse.

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.

How deletion actually works#

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.

• You can erase a contact yourself, from inside InsideDM. Their conversation history goes with them.
• A person can come to us directly to stop being messaged or to be deleted, without going through the business first — see section 1.
• Meta’s deletion requests are honoured. If you ask Meta to delete your data from InsideDM, Meta sends us the request: we revoke the Instagram connection and destroy our access to it straight away, and erase the conversations and customer records that came to your business through that account — and only that account — within 30 days. Meta gives you a confirmation code and a page where you can follow the request. We keep a record of the request itself — the Meta account id it named, when it arrived and which connections it reached — as proof it was carried out; it holds no conversations or customer details. When you remove InsideDM from your Meta Business Settings, Meta tells us and we delete the WhatsApp credential we held for that number. A deletion request for a Facebook account that connected WhatsApp cannot yet be matched to it automatically; until it can, email us and we act on it within the window on our Delete your data page.
• What went to other tools is asked back. When a customer is erased, we ask every sheet, CRM or webhook an enquiry of theirs was sent to, and every calendar a booking of theirs was written to, to delete it — and keep asking until each one confirms.
• Shopify’s redaction requests are honoured — customer and shop redaction requests are processed within their required window.
• You can delete your whole account from your settings. We show you what will be removed before you confirm.

Every one of these routes, with the exact wording to send us and what to expect back, is on one page: Delete your data.

Your rights, and how to use them#

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.

How we protect it#

• Encrypted in transit, and at rest in our managed database.
• Merchant credentials and access tokens are encrypted with a dedicated key, never stored in plain text.
• Personal data that must survive the deletion of surrounding records is encrypted under a per-person key, so erasure can destroy it precisely.
• Each business's data is stored separately from every other business's, and access is scoped per workspace with roles and permissions.
• Staff access to production data is limited to the people who need it to run the service.
• Webhooks from Meta, Shopify and payment providers are signature-verified before we act on them.

Cookies and the website#

We use cookies to keep you signed in and to keep your session secure. We also use one analytics tool, Microsoft Clarity, to see how our pages are used — which links people click, where they scroll, and where a page confuses them.

Clarity records a session as a picture of the page and the actions taken on it. On our public website that picture is ordinary marketing copy. Inside the dashboard it is masked: we send the shape of the screen — layout, clicks, scrolling — and none of the words. Your customers’ names, phone numbers, and the text of their messages never leave your browser for Clarity. Anything you type into a field is never captured, anywhere on the site.

Clarity sets its own cookies, and Microsoft sets cookies of its own alongside them — including one (“MUID”) that Microsoft also uses for advertising on its own services. We do not advertise, we run no ad campaigns, and we do not build profiles of you or target you. But we should be straight about it: Microsoft receives this data as an independent controller, under its own privacy statement, not merely as a supplier acting on our instructions. Recordings are kept for 30 days and heatmaps for nine months. If you would rather not be included, your browser’s “do not track” and cookie-blocking settings will exclude you, and you can write to us at the address in the Contact section.

Beyond that there are no advertising pixels and no other third-party analytics on insidedm.in.

Our web server keeps ordinary request logs — IP address, browser, page and time — for security and debugging.

If you write to us through the contact form, we receive what you put in it: your name, email address and mobile number, the reason you picked or the message you wrote, and your website or Instagram handle if you add one. Zoho ZeptoMail delivers it to our team’s inbox as an email. We use it only to get back to you — by email, or by calling or messaging the number you gave — and you can ask us to delete it by writing to privacy@insidedm.in.

Children#

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.

Changes, contact and complaints#

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.

The company behind InsideDM

Grievance Officer

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.