Deleting a Person in Customer.io Isn't a Right-to-Be-Forgotten Button. Without Suppress, They Come Back Unsubscribe-Free

In 2003, Barbra Streisand tried to make a photograph disappear. An aerial shot of the California coastline, part of a 12,000-image survey documenting erosion, happened to include her clifftop house in Malibu. She sued the photographer, Kenneth Adelman, and the site hosting the image for $50 million, demanding the picture come down.

Before the lawsuit, that photo had been downloaded six times. Two of those were by her own lawyers. Once the case hit the news, more than 420,000 people went looking for it in a single month. The case was dismissed, and the backfire earned a name that stuck: the Streisand effect.

Deleting a person in Customer.io carries a quieter version of the same risk. You click the button that promises to erase someone. You assume they're gone for good... and weeks later they land back in your database, unsubscribe wiped, ready to receive the emails they'd just asked to stop. Not because of publicity. Because delete, on its own, doesn't make them stay gone.

Customer.io gives you two different actions for a person you want rid of: delete, and suppress. They sound like the same thing at different volume. They aren't. Delete removes the data. Suppress is what stops the person coming back. For a right-to-be-forgotten request you almost always need both, and the docs are specific about why. Here's what each action does, where the trap is, and the exact steps to honour an erasure request without leaving the door open.

"Delete forever" removes the data but not the identifier

When you delete a person in Customer.io, you remove all of their data, permanently, with no way to get it back. That part does exactly what the button says. Customer.io's documentation on deleting profiles is blunt: "when you delete a profile, you're deleting their data with them too. There is no way to recover a deleted profile's data."

So far, so good for an erasure request. The problem is what delete leaves untouched: the identifier. The email address, the ID, and the phone number that pointed at that person are all freed up again. Delete empties the record. It doesn't lock the door behind it.

It helps to be clear on what deletion is not. An unsubscribe isn't a deletion. When someone unsubscribes, Customer.io keeps their profile and sets an attribute to mark them as unsubscribed. They stay in your workspace on purpose, so you don't message them again. If you've ever wondered what that opt-out is worth as a signal, we've written about what the unsubscribe button is telling you. Deletion is the opposite move: the whole record goes. And that gap is exactly where erasure requests go wrong.

Without suppress, a deleted person comes back clean

Here's the trap in one line: delete a person without suppressing them, and anyone, or anything, can re-create them from the same email or ID with a completely clean slate.

Customer.io spells out what "clean slate" means. A profile you re-add with a previously deleted identifier "will have no prior data, including their unsubscribe status: the re-added profile can trigger previously received automations." Read that twice. No unsubscribe status. The person who opted out, whose data you deleted in good faith, returns eligible for every automation they'd already left.

And you rarely re-add them on purpose. If you feed Customer.io data from anywhere else, a webhook, a reverse-ETL sync, or the JavaScript snippet on your site, that source can quietly recreate a deleted profile the next time it runs. The docs say it plainly: if you send data by other means, "you can re-create profiles you've deleted." The more pipes you have running, the likelier it is. Our guide to integrating data sources with Customer.io gives a sense of how many of those there usually are.

There's a second-order effect worth knowing. The old activity doesn't move to the new profile. Customer.io keeps the deleted person's history attached to their cio_id, the internal identifier it generates and never changes, and a re-created profile "does not regain the activity history of the previously deleted profile." You don't even get continuity out of it. You get a stranger wearing the same email, with none of the context and none of the preferences.

This is also why the missing unsubscribe bites harder than it first looks. Customer.io's global unsubscribe is a single all-or-nothing flag rather than something granular, so when a re-added profile loses it, it loses the one switch that was keeping the person out of everything.

Suppress is the action that actually forgets them

Suppress is what makes deletion stick. When you suppress a person's identifiers, Customer.io blocks those identifiers from ever being added to your workspace again, and redacts the activity tied to them. In the profile history, suppressed identifiers show up as forgotten (anonymous). That is the state a real erasure request is asking for: not just the data gone, but the door bolted so the same person can't be silently rebuilt.

Customer.io treats suppression as the stronger, more deliberate step. Deleting a profile removes someone's data. Suppression goes further: "in extreme cases, when a person indicates that they never want to be messaged again, you can suppress their identifiers." Do that, the privacy docs note, and "even if they make themselves known to you, they won't be added to your workspace or be eligible to receive messages." Delete answers "remove my data". Suppress answers "and never contact me again".

One thing to clear up, because the word is overloaded. Suppress means at least three different things in an email stack, and only one is what we're discussing. There's GDPR identifier suppression, the subject of this post, which blocks an identifier from being re-added. There's fatigue or frequency suppression, which just holds back a send because someone has had too many messages lately... a deliverability-and-respect tactic we've covered in the art of not sending. And there's ESP suppression, the list your email provider keeps of addresses that hard-bounced or filed a spam complaint. Customer.io keeps that last one under Workspace Settings when you use it as your ESP, and it exists to protect your sender reputation, not to honour a data request. Same word, three jobs.

How to delete and suppress over the API

If you're honouring erasure at any scale, you'll do this over the API, and one detail saves you a step: suppressing a profile also deletes it. You don't call delete and then suppress. Customer.io is explicit: "Suppressing a profile through our API also deletes a profile. You don't need to call both the delete and suppress endpoints." The call is a POST to /api/v1/customers/:identifier/suppress. The Track API reference describes it the same way, as an operation that deletes the profile and prevents the person's identifiers from being re-added to your workspace.

Once an identifier is suppressed, Customer.io ignores future API calls that reference it, and an attempt to re-add that person "results in an error." That's the lock working as intended.

Suppression is reversible, with a catch. You can unsuppress an identifier from Workspace Settings, or through the API, to free it up again. But unsuppressing doesn't bring the person back. If you then re-add them, Customer.io makes "a new profile without any history (messages, journeys, etc.)." Undoing a suppression is not undoing a deletion. The data is still gone; you've only unlocked the identifier.

Two operational details are easy to miss. First, if your account is on EU data residency, use the endpoints that begin with track-eu. Customer.io routes US endpoints to EU accounts, but the traffic still passes through US servers and may be logged there, which rather defeats the point for a privacy request. Second, the v1 suppress endpoint reads the identifier in the URL as an id or email only. To suppress someone by phone number, use the Track v2 API, though suppression still covers all of a person's identifiers whichever one you reference.

What gets suppressed depends on your workspace

What suppression blocks depends on how your workspace identifies people, and the two setups behave differently. If your workspace is ID-only, suppressing a profile suppresses their ID. If your workspace identifies people by email, phone, or ID, suppressing one person blocks all of it: you can't add another profile with the same id, email, or phone. Either way, suppression covers every identifier on the profile, not just the one you pointed at.

One migration trap sits inside this. If you run an ID-only workspace and later switch it to identify by email or ID, the email addresses of already-suppressed profiles get suppressed too. That's usually what you want for erasure, but it can catch you out if you weren't expecting old suppressed records to start blocking email addresses.

A simple runbook for an erasure request

When someone asks to be forgotten, this is the sequence that actually honours it. It's operational guidance, not legal advice... what you owe under GDPR or any other regime is for you and your lawyers to settle.

1. Delete and suppress in one action. In the UI, click Delete forever, then choose to suppress the identifiers in the confirmation dialogue. Over the API, call the suppress endpoint, which deletes as well.
2. Use the right region. On EU data residency, call the track-eu endpoints so the request isn't routed through US servers.
3. Confirm it took. The person's activity should read forgotten (anonymous), and a re-add attempt should error rather than quietly succeed.
4. Close the side doors. Check that no integration, webhook, reverse-ETL sync, or on-site snippet is about to re-import the same person from an upstream system. Suppression blocks the identifier, but you don't want a pipeline throwing errors on every sync either.

Customer.io positions these as the tools for the job. Its GDPR statement lists a "right to be forgotten" capability, honoured "by calling the DELETE API or using the UI". It also documents a separate "automatic suppression" endpoint that blocks incoming data for people exercising the right to object. Delete is the erasure. Suppress is what keeps it erased.

Worth saying: erasure is one of several Customer.io settings where the default isn't the compliant option. If you'd rather have someone set this up properly, from the erasure process to your consent and tracking defaults, that's the kind of work we do, and you can tell us what you need.

Frequently asked questions

What is the difference between deleting and suppressing a person in Customer.io?

Deleting removes all of a person's data permanently but leaves their identifier free to be reused; suppressing blocks that identifier from ever being re-added and redacts their activity as forgotten (anonymous). For a right-to-be-forgotten request you usually want both, which is why Customer.io lets you delete and suppress in a single step. Delete answers "remove my data"; suppress answers "and don't let me back in".

If I delete someone without suppressing them, can I add them back?

Yes. Customer.io's docs state that once you delete without suppressing, "you can reuse a deleted profile's email or ID to create a new profile." That re-add can happen deliberately or automatically, from a CSV import, an API call, or any integration still sending you that person's data. Suppressing the identifier is what prevents it.

Does a re-added person keep their old unsubscribe status?

No, and this is the dangerous part. A profile re-added with a previously deleted identifier "will have no prior data, including their unsubscribe status", which means it "can trigger previously received automations." Someone who opted out can be rebuilt as a fresh, subscribed profile and re-enter the automations they had left.

Does unsubscribing remove someone from Customer.io?

No. When a person unsubscribes, Customer.io keeps their profile and sets an attribute marking them unsubscribed, rather than deleting them. That's deliberate: the record has to stay so the platform knows not to message them. Deleting a profile is a separate, heavier action meant for actual erasure requests.

How do I properly honour a GDPR erasure request in Customer.io?

Delete and suppress the person's identifiers in one action. In the UI, click Delete forever and choose to suppress in the dialogue; over the API, call the suppress endpoint, which also deletes. On EU data residency, use the track-eu endpoints, then confirm the activity reads forgotten (anonymous). This is operational guidance rather than legal advice, but it maps to the "right to be forgotten" and "automatic suppression" capabilities Customer.io documents in its GDPR statement.

Do I need to call both the delete and suppress endpoints?

No. Suppressing a profile through the API also deletes it, so a single suppress call does both jobs. In Customer.io's words, "You don't need to call both the delete and suppress endpoints." Calling delete first and then suppress is redundant.

Can I undo a suppression, and what happens if I do?

You can unsuppress an identifier, from Workspace Settings or the API, to make it usable again, but it does not restore the person. If you re-add them afterwards, Customer.io creates "a new profile without any history (messages, journeys, etc.)." Unsuppressing frees the identifier; it doesn't recover the deleted data.

Does deleting a person restore their history if I re-create them?

No. Deleted data is unrecoverable, and a re-created profile "does not regain the activity history of the previously deleted profile." The old activity stays attached to the original person's cio_id, the internal identifier Customer.io generates, not to the new profile you have just made.

What does "forgotten (anonymous)" mean on a profile?

It's how Customer.io marks activity that belonged to a suppressed identifier. After you delete and suppress someone, "profile activity shows forgotten (anonymous) entries for suppressed identifiers", so the events survive in aggregate but are no longer tied to an identifiable person. Seeing it is a good way to confirm a suppression actually took.

Which identifiers get suppressed, just the email?

All of them. Suppressing a profile suppresses every identifier on it. In an ID-only workspace that's the ID; in a workspace that identifies people by email, phone, or ID, you then can't add another profile with the same id, email, or phone. It doesn't matter which identifier you reference in the call.

Do EU accounts need a different endpoint to suppress a person?

Yes. If your account is on EU data residency, use the endpoints beginning with track-eu. Customer.io redirects US endpoints to EU accounts, but that traffic still passes through US servers and may be logged there, which defeats the point of EU residency for a privacy request.

Is deleting a person in Customer.io reversible?

No. There is no way to recover a deleted profile's data, whether or not you suppressed it. Suppression is reversible in the narrow sense that you can unsuppress the identifier, but the underlying data stays gone. Treat every delete as permanent.

Sources

• Delete profiles and suppress profile IDs. Customer.io Docs, updated 15 July 2026.
• Respecting your users' privacy. Customer.io Docs, updated 15 July 2026.
• Track API reference: suppress and unsuppress. Customer.io Docs.
• Transfer Impact Assessment and GDPR Compliance Statement. Customer.io, revised March 2024.
• The Streisand effect. Wikipedia (documents the 2003 lawsuit, the six prior downloads, and the 420,000 subsequent visitors).