Compliance · 5 min read
What an Instagram Automation Tool Stores About Your Commenters
Somebody comments "price" under your Reel at eleven at night. By the time you wake up they have had a reply, and there are now records in a database with their handle on them. This post is about which records, where they sit, and what happens the day that person writes to you asking for a copy of everything you hold.
Most privacy pages answer that with a paragraph of reassurance. Reassurance is not an answer. The useful version is a list.
What arrives, and where it comes from
Everything starts as an event Meta delivers. Nothing is scraped, and nothing is read out of your phone.
When a comment fires an automation, the things written down are the comment text, the commenter's Instagram-scoped identifier and public handle, the post it was on, the timestamp, which trigger matched, and the reply that went out. If the reply was refused, the refusal is written down instead, with the name of the check that stopped it.
When a DM thread is involved, the messages in that thread are stored so the Inbox can show them to you and so the AI has something to answer. A DM you can see in the product is a DM the product is holding.
If you turned on capture-to-Leads, there is also a lead record. It holds what the person actually typed. An email address exists on that record because they wrote an email address in a message — not because we found it somewhere.
What is not there
This half matters more than people expect, because it is the half that decides how bad a breach would be.
There is no follower list. There is no email appended from a data broker. There is no phone number inferred from a handle. There is no Instagram password, because the official Graph API never involves one — you authorise through Meta and the product receives a scoped token. There is no browsing history, no location, no device fingerprint beyond what any web application receives when you load a page.
The safest data is the data that was never collected. Most of what a scraping tool holds, an API tool never had.
The practical consequence: the worst-case disclosure here is "the public comments people left you, the DMs they sent you, and the replies you sent back". That is bad. It is not the same order of bad as a scraped contact database.
Retention, honestly
Message and comment records stay for as long as the workspace does, because the Inbox and Activity would be useless otherwise — a thread that disappears after thirty days is a thread you cannot audit when somebody complains. Leads stay until you delete them or delete the workspace.
That is a design choice, not a legal position. Whether that retention is appropriate for your business is your call, and it depends on where you and your customers are.
The export and the erasure are the same list
Here is the part I would actually check if I were evaluating somebody else's product.
There is an endpoint for a data request. It produces a downloadable export. There is a separate endpoint for erasure. The interesting bit is that both are driven by one list of fifty tables, in a fixed order — the same list. So the answer to "what can I download" and the answer to "what gets deleted" cannot drift apart. Add a place where data lives, and either it goes on the list or it appears in neither.
Most products get this wrong in a boring way: the export was written first, six months of features happened, and the erasure routine quietly stopped matching. You cannot tell from outside. You can only tell by asking whether they are one list or two.
Erasure marks the workspace as erased rather than dropping the row. That sounds like a hedge and it is the opposite of one: because the parent row survives, the database's own cascade rules will not clean up after us, so every dependent table had to be named explicitly. The tombstone forced the list to be complete.
The nominee
There is also a nominee endpoint — you record who inherits access to the workspace. It is an unglamorous feature that exists because accounts outlive the arrangements people made around them, and "the founder had the login" is a real failure mode, not a hypothetical one.
What a person can ask you for, and what you do about it
When a commenter writes to you rather than to us, remember which way round this is. They are your customer. Their messages are in your workspace. You are the one who decided to run an automation on your posts.
In practice the requests fall into three shapes:
- "What do you have on me?" You can pull the export and see the messages, the replies, and the lead record if there is one. The honest answer is usually shorter than they fear.
- "Delete it." Deleting the lead record removes the captured details. Deleting the whole workspace runs the erasure path across the full list. Be clear with yourself about which one you have actually done.
- "Stop messaging me." Cheapest to honour and easiest to forget. A person who has told you to stop should not be re-triggered by their next comment, and if you cannot promise that, narrow the automation instead of promising it.
The related question — what obligations you pick up by running the automation in the first place — is its own post, because it is a different subject wearing similar words.
The thirty-second version
Comments, DMs, replies, refusals with their reason, and leads made of what people typed. No scraped contacts, no password, no follower list. Export and erasure driven by one list so they cannot diverge, and a tombstone that made the list prove itself.
If a vendor cannot describe their own storage in that much detail, that is the finding. The rest of the audit is fifteen minutes of questions, and it is worth doing before you connect an account rather than after.
