Klaviyo Suppress vs Unsubscribe via the API

We had a list of profiles that needed to stay retired. Every one of them was suppressed in Klaviyo, but suppression turned out to be weaker than we assumed: any tool or script with API access can remove a manual suppression, and a growing category of suppression-management tools does exactly that when their models decide someone might engage again. We wanted a block that nothing could quietly reverse.

The answer was to unsubscribe them through the API instead. That sentence hides two things we had to test to believe: the unsubscribe endpoint works on profiles that never subscribed in the first place, and the resulting state can't be cleared by any suppression call. This post is what we verified, on a live account, plus the one honest caveat about reversibility.

Can You Unsubscribe Never-Subscribed Profiles via the API?

Yes. Klaviyo's subscription bulk delete endpoint moves a profile's email consent to UNSUBSCRIBED regardless of its starting state, including NEVER_SUBSCRIBED. That last part matters for ecommerce accounts, where a big share of profiles were created by checkouts, imports, or integrations and never gave explicit consent. They sit in an implicit, mailable state, and this endpoint is the bulk path for revoking it.

POST /api/profile-subscription-bulk-delete-jobs/

{"data": {"type": "profile-subscription-bulk-delete-job",
  "attributes": {"profiles": {"data": [
    {"type": "profile", "attributes": {"email": "person@example.com"}}
  ]}}}}

Up to 100 profiles per job. It's async, so give it a minute or two before checking the profile. Omit the list relationship and it's a global unsubscribe from all email marketing. Pass one and the unsubscribe is scoped to that list, with a gotcha straight from Klaviyo's docs: profiles not in the specified list still get globally unsubscribed, so verify membership first. One more detail worth knowing: if an email in your payload doesn't match an existing profile, Klaviyo creates a new profile and unsubscribes it, so typos become phantom profiles instead of errors.

The Three States That Block (or Don't Block) Email

Suppress vs unsubscribe sounds like two names for the same thing, and in the UI both look like "this person doesn't get mail." The difference is who can turn them back off.

Suppression is a removable flag. Unsubscribed is a consent record. Klaviyo's suppression-delete endpoint (the "unsuppress" call) is explicit about the boundary: "This only removes suppressions with reason USER_SUPPRESSED; unsubscribed profiles and suppressed profiles with reason INVALID_EMAIL or HARD_BOUNCE remain unchanged." So once a profile is unsubscribed, no suppression operation, manual or automated, makes it mailable again.

What Actually Happens on the Profile

We ran this on a profile that had been manually suppressed for over two years, with NEVER_SUBSCRIBED consent. After the job processed, the profile read consent: UNSUBSCRIBED with a fresh UNSUBSCRIBE suppression, and the old USER_SUPPRESSED record was gone. Klaviyo doesn't stack the two. The unsubscribe supersedes the manual suppression.

One quirk worth knowing before you run this at scale: the profile's activity log shows two events in the same second, "Manually Unsuppressed from Email Marketing" followed by "Unsubscribed from Email Marketing." Here's the actual log from our test profile:

That first event is just how Klaviyo logs the removal of the old suppression record as part of writing the stronger state. There is no mailable gap between them. But if you bulk-run a few hundred of these, anyone skimming the account activity feed will see a burst of "manually unsuppressed" events and may reasonably panic. Tell your team (and your client) before they see it.

Why Bother: Suppression Is a Convention, Consent Is a Wall

If you're the only one touching the account, suppression is fine. The gap shows up when other hands have API keys. Suppression-management tools unsuppress profiles by design: their whole pitch is rescuing people their models think were suppressed too aggressively. Integrations re-sync audiences. A teammate cleans up "stale" suppressions without the context. A "do not resuppress" naming convention only works while everyone honors it.

So the suppress vs unsubscribe call comes down to one question: is there any future where you want this profile back?

• Use suppression for anything you might want back: sunset segments, deliverability cooldowns, pauses. It's the reversible tool, and that's a feature. We use it for do-not-contact lists where the client may later clear names, for automated list hygiene, and for profiles we later reactivate deliberately.
• Use unsubscribe for profiles that should never be mailed again no matter what tooling touches the account: hard do-not-contact requests, legal removals, dead segments you've decided are permanently retired. Check purchase history first. Never-subscribed profiles include past buyers, and this closes the door on them from your side.

Not sure which of your suppressed segments should be walls instead of flags? That's the kind of thing we sort out in a free Klaviyo audit.

Can the API Resubscribe an Unsubscribed Profile?

Yes, and it's worth being precise here because most answers online get it wrong in one direction or the other. Klaviyo's bulk subscribe endpoint states that it "will remove any UNSUBSCRIBE, SPAM_REPORT or USER_SUPPRESSED suppressions from the provided profiles." So a deliberate subscribe job with consent set will bring an unsubscribed profile back.

The protection isn't that reversal is impossible. It's that reversal requires someone to explicitly assert the person consented, which is a compliance claim, not a cleanup operation. No suppression tool makes that call as a side effect, and nobody should make it without an actual opt-in behind it. Unsubscribe is proof against accidents and automation. It is not proof against a person determined to make a consent claim they can't back up, and nothing in Klaviyo is.

The One-Liner

We built this into klaviyo-cli, our open-source Klaviyo command line (GitHub, PyPI), as of v0.4.0. It batches at the 100-profile cap, supports list scoping, and asks for confirmation before it runs, since this is real people's consent:

klaviyo unsubscribe --file emails.txt
klaviyo unsubscribe --emails a@x.com,b@y.com --list LIST_ID

We deliberately did not wrap the subscribe endpoint. Reversing consent revocation should stay a conscious, raw-API act, not something one flag away from a cleanup script.