SMS Opt-Out Support With an AI Agent: Can It Handle 'Stop Texting Me' in Klaviyo, Attentive, Postscript and 11 More Apps? (2026)

Which email and SMS apps let an AI agent process an opt-out?

We read each vendor's developer docs and Shopify App Store listing on 28 September 2026. "Static key" means the merchant creates a token once and the agent sends it on every call, with no shopper login and no token that expires every few hours. The last-but-one column answers the question support teams hit most: the shopper emailed "stop texting me" from an email address, so can the agent find and stop their texts without asking for a phone number?

Ratings and review counts are each app's Shopify App Store listing on 28 September 2026, except Sendlane, whose listing didn't load that day; its figure is from our 25 September check. Review counts undersell enterprise tools: Attentive has 111 reviews and is a Gorgias preferred partner.

The apps built for SMS first (Attentive, Recart) key everything on the phone number, so an email-only request needs one more question to the shopper. And three of the eight reachable apps put a condition on API access: Postscript wants an enterprise plan, Privy a paid account, and Recart issues keys through its support team rather than a settings page.

Why does a "stop texting me" email have to reach the marketing app?

Because the law treats that email as the opt-out itself. The FCC's rule at 47 CFR 64.1200(a)(10) lets a consumer revoke consent to marketing texts "by using any reasonable method", says replies of STOP, QUIT, END, REVOKE, OPT OUT, CANCEL or UNSUBSCRIBE are reasonable by definition, and requires the revocation to be honored "within a reasonable time not to exceed ten business days". Paragraph (a)(11) then covers the support inbox directly: an email "to any telephone number or email address intended to reach the caller" creates a rebuttable presumption that consent was revoked.

Email marketing has its own clock. The FTC's CAN-SPAM compliance guide says "you must honor a recipient's opt-out request within 10 business days" and that the opt-out mechanism must keep working for 30 days after a send.

The texting side is where the money is. The TCPA's private right of action at 47 U.S.C. 227(b)(3) allows $500 per violation, and a court can triple that for a willful one. Take a synthetic case: a brand sends three marketing texts a week, a shopper emails support asking them to stop, and the ticket sits in a queue. Once the ten business days (two weeks) are up, every text is a potential violation. Four more weeks of sends is 12 texts, $6,000 at $500 each, or up to $18,000 if a court finds it willful. This isn't legal advice, and real cases turn on facts, but it shows why "we'll get to it" isn't a policy for this ticket type.

The rule also lets the brand send exactly one confirmation text, with no marketing in it, presumed fine if it goes out within five minutes. Several of the APIs below send that text for you.

What does each app's opt-out call actually do?

The vendor docs differ more than the table can show. These are the details that change what an agent should do.

Klaviyo unsubscribes through a bulk job that takes up to 100 profiles per call and runs asynchronously. Leave out the list ID and the unsubscribe is global, which is usually what "unsubscribe me" means. Every call needs two fixed headers: the private key and a revision date. The Klaviyo page covers scopes, suppression and the revision lifecycle.

Attentive has one unsubscribe endpoint for both channels, but a phone number only reaches text subscriptions and an email only reaches email ones, and the endpoint is capped at 5 requests a second. The Attentive page covers its confirmation text and privacy deletions.

Postscript is the strictest on access. Its developer docs say custom API access for individual shops has been "limited to those on enterprise plans" since April 2022; shops on other plans can create keys only for Postscript's integration partners.

The policy is optimized for Postscript's partner ecosystem: custom work goes through partners, or through contracts big enough to justify the support load. For a support agent the practical result is simple. On an enterprise plan, PATCH /api/v2/compliance/unsubscribe takes a phone_number or a postscript_subscriber_id, returns 202, and returns 404 if nobody matches. It doesn't take an email, so an email-only request needs a lookup first: GET /api/v2/subscribers?email__eq=... returns the subscriber ID. Postscript also has a Redact endpoint that accepts an email and "will also unsubscribe", but it also deletes the subscriber's data, which makes it a privacy request.

Privy puts consent in two fields on the contact. PATCH /v1/contacts/{id} accepts email_consent (subscribed, unsubscribed, never_subscribed, suppressed) and sms_consent (subscribed, unsubscribed, never_subscribed, single_opt_in). A contact Privy suppressed for compliance reasons is read-only on email and returns 422 if you write to it. Setting sms_consent to subscribed makes Privy send "a TCPA-required welcome SMS" unless the call sets send_welcome_sms to false.

Privy's API tokens start with privy_, can be set to expire in 30, 60 or 90 days, a year, or never, and share one budget of 60 requests a minute and 10,000 a day per account. For an agent tool, pick a one-year token and put the renewal date in a calendar: a token that silently expires turns every opt-out into a failed call. The API is only available on paid Privy accounts.

Omnisend changes consent per identifier. PATCH /api/contacts?email= updates the contact, and each identifier (the email, or the phone in E.164 format) carries its own channel status: subscribed, unsubscribed or nonSubscribed. So to stop texts, the agent reads the contact first to get the phone identifier, then sets that identifier's SMS status. Two headers are required, Authorization: Omnisend-API-Key ... and Omnisend-Version: 2026-03-15, and the default limit is 400 requests a minute per brand. We found no delete-contact endpoint in the current API version, so deletion requests are a person's job.

Mailchimp has the trap most likely to fool a well-meaning tool builder. The DELETE method on a list member doesn't unsubscribe anyone; Mailchimp's reference calls it "Archive list member". The unsubscribe is a PATCH that sets status to unsubscribed, addressed by the MD5 hash of the lowercase email. The other delete, POST .../actions/delete-permanent, removes the member's personal data and "will make it impossible to re-import the list member". Mailchimp allows 10 simultaneous connections per account, which a ticket-by-ticket agent won't notice.

Drip has a naming trap of its own. POST /v2/{account}/subscribers/{id_or_email}/remove takes someone out of email series campaigns, and Drip's docs note it "was previously labeled unsubscribe". The call that stops all mail is unsubscribe_all. Drip authenticates with the API token as the Basic-auth username and allows 3,600 requests an hour.

Recart is SMS-first and phone-only. DELETE /subscriptions?phoneNumber= unsubscribes "if it's not unsubscribed yet" and returns 204, and the subscriber lookup takes a phone number and never returns a phone, email or name. REST keys are "issued by Recart support, not self-serve", sent as X-Recart-API-Key. Recart also runs an MCP server for AI clients, and it's read-only by design, so an assistant connected there can't opt anyone out.

Which apps can't an AI agent reach, and what should it do instead?

Six of the 14, for four different reasons.

Consent lives in Shopify. Shopify Messaging has no API of its own; its consent is the email and SMS marketing state on the Shopify customer, which Shopify's Admin API changes through customerEmailMarketingConsentUpdate and customerSmsMarketingConsentUpdate. Seguno works the same way: its help center says it "does not maintain a separate contact database" and a subscriber is "a Shopify customer with an Email subscription status set to Subscribed". Macha's built-in Shopify connector reads orders, products and customers and can issue refunds, but it has no consent tool. Shopify's changelog of 30 October 2025 says new custom apps can't be created in the Shopify admin from 1 January 2026. Existing custom apps "aren't affected and will continue to work", and new ones are built in Shopify's Dev Dashboard instead. So a store that already has an admin-created custom app with the customer write scope has a token a custom tool could use, and a store without one would go through the Dev Dashboard. Consent writes to the Shopify customer are not something we set up today, so for these two the agent confirms the request and hands the ticket to a person with admin access.

No public API. We found no public API for AfterShip's email and SMS app in AfterShip's developer docs, and no public API reference for Emotive, which Privy now owns. Emotive issues a personal access token for partner integrations such as Privy's, but without documented endpoints there's nothing to build a tool on.

Docs behind a login. Sendlane has an API v2, but its reference sits behind a sign-in, so we couldn't confirm an unsubscribe endpoint. Treat it as unverified until someone with an account checks.

Retired. Yotpo's SMS and email product (formerly SMSBump) has been decommissioned; smsbump.com says it "has officially reached its end of product lifecycle". Brands still referencing it in macros or help articles should update them.

For every app in this group, the agent's job is the same: acknowledge the request in writing, say who will action it and by when, tag the ticket so it can't sit, and route it to whoever holds the admin login. The written acknowledgement matters, because it's also your record of when the ten-day clock started.

What do the help desk integrations already handle?

They move conversations into the ticket and leave consent where it was. The Attentive and Postscript integrations with Gorgias turn SMS replies into tickets and let agents reply by text; Postscript's Gorgias docs add that "you can't start an SMS conversation with a shopper from your helpdesk". Privy's Gorgias integration says consent keywords "(STOP, HELP, START) are handled by Privy and never clutter your Gorgias inbox". Recart forwards replies to Gorgias and Gladly. The Klaviyo integration for Gorgias and the Klaviyo app for Zendesk show profile data and turn replies into tickets. None of the integration docs we read describes changing a subscriber's consent from the ticket.

That split follows each vendor's incentive. Marketing platforms build help-desk integrations so replies to campaigns get answered, because an answered text often turns into an order. Removing a subscriber is the one action that shrinks the thing they bill on, so it stays inside their own product, where they control how it happens.

Inside their own products, the marketing apps catch a lot. Keyword replies to the SMS number are processed automatically everywhere. Klaviyo turned on unsubscribe detection by default for US numbers after the FCC change. Recart goes furthest: it uses AI to catch opt-out intent in free-text replies, including "please stop texting me", stop emojis and misspellings like "Dtop", and has it on for all accounts without setup.

The gap is everything that doesn't arrive as a reply to the marketing number: an email to support, a chat message, a contact form, a phone call logged as a ticket, a comment on an order. Those are exactly the channels an AI agent working the help desk sees first.

Which opt-out requests should stay with a person?

Most shouldn't. An opt-out is the rare support action where acting fast is lower risk than waiting: a shopper who changes their mind can sign up again through a form, while a late opt-out can't be undone. A sensible split:

• The agent does it: "unsubscribe me", "stop texting me", "stop the emails" from the address or number on the ticket, scoped to the channel the shopper named. Reply with what stopped and what (like order updates) didn't.
• The agent does it, then flags: "stop everything" on an app that sends order updates too. The opt-out calls above change marketing consent, so ask the agent to say in the reply that order and shipping updates still arrive, and to hand off if the shopper wants those stopped as well.
• A person: data deletion requests (Postscript's Redact, Mailchimp's delete-permanent and Klaviyo's deletion job can't be undone; our data privacy page covers how Macha handles its own copy), re-subscribes (Privy sends a welcome text; double opt-in may apply elsewhere), "wrong number" messages from someone who isn't the subscriber, and every app in the not-reachable group.

Building the opt-out tools in Macha

None of these apps is a built-in Macha connector. Each of the 8 reachable ones connects through a custom API tool that Macha's team sets up during onboarding, and custom tools are included on every plan. A custom tool is an HTTP call with fixed headers, parameters the agent fills in, and a type: Read for lookups, Write for changes. Custom tools can send more than one fixed header, which Klaviyo and Omnisend both need. The credential is stored encrypted and never shown to the model.

The build order we'd use for any of them:

1. A scoped key. Only the permissions the tools need: contacts_write on Privy, Subscribers on Attentive, the consent scopes on Klaviyo. On Postscript, check the plan first; on Recart, ask Recart support for a REST key.
2. A lookup tool (Read) that finds the subscriber by email or phone and returns their consent, so the agent can tell "already unsubscribed" apart from "never subscribed".
3. One Write tool per channel, such as "Stop marketing texts" and "Stop marketing email", with the channel fixed in the body rather than chosen by the model. Don't count on a confirmation card to catch a bad write. In our tests the built-in Zendesk write tools paused for a card in chat, but a custom Write tool ran without one, even though the tool editor labels it "Write (requires confirmation)", and on a triggered run a Write tool runs directly if the instructions say to. That's why the instructions below spell out when to opt someone out and when to hand off.
4. A test with the tool's Test button against a test subscriber before the tool is assigned. The custom API tools guide covers parameters and body templates.

An instruction block for the agent, written for a store running Klaviyo for email and Postscript for SMS:

When a customer asks to stop marketing emails or texts, in any words, on any channel:
1. Decide the channel: "texts", "SMS", "messages to my phone" = SMS. "emails", "newsletter" = email. "everything", "all of it" = both.
2. SMS: run "Postscript: find subscriber" with the phone on the ticket (format +1XXXXXXXXXX). If there is no phone, run it with the email. If nothing matches, ask the customer for the number the texts arrive on and stop.
3. SMS: run "Postscript: unsubscribe" with the subscriber ID from step 2.
4. Email: run "Klaviyo: look up consent" with the email, then "Klaviyo: unsubscribe email" if the profile exists. Never pass a list ID.
5. Reply confirming exactly which messages will stop, and that order and shipping updates still arrive. Tag the ticket "marketing-opt-out".
Hand off to a human, with the lookup results attached, for: requests to delete data, "wrong number" messages, and any request to sign back up.

The agent answers the ticket in the help desk as usual, so the reply, the tool calls and the tag are all on the ticket: the record you'd want if anyone later asks when the opt-out was honored.

What happened when we ran an Omnisend opt-out agent on a test ticket

We built the Omnisend version of this on 28 September 2026, because an Omnisend contact carries both channels, so the agent has to change the right one and leave the other alone. On our Macha Demo test org we created three custom tools with a dummy key: "T4B-Omnisend: Find contact" (GET /api/contacts?email=, Read), and "T4B-Omnisend: Stop marketing texts" and "Stop marketing email" (both PATCH /api/contacts?email=, Write). Each sends the key as Authorization: Omnisend-API-Key ... plus a fixed Omnisend-Version: 2026-03-15 header. The texts tool's body sets one phone identifier's sms status to unsubscribed; the email tool's body sets the email identifier's email status and leaves SMS alone.

Pressing Run Test on the texts tool, with a made-up email and a 555 phone number, got HTTP 401 back with Omnisend's own error body (problems.omnisend.com/unauthorized). A wrong key can only prove that much: the request reached Omnisend with both headers and was refused. It says nothing about what a successful PATCH returns.

We then created an inactive agent, "T4B-Omnisend opt-out helper", with four Zendesk tools, the three Omnisend tools and this instruction:

When a customer asks to stop marketing messages, in any words, on any channel:
1. Decide the channel from their words. "texts", "SMS", "STOP", "messages to my phone" = SMS. "emails", "newsletter" = email. "everything", "all of it" = both. If they say one channel is fine, leave that channel alone.
2. Run "T4B-Omnisend: Find contact" with the requester's email. If no contact comes back, ask for the email or phone number the messages arrive at, and stop.
3. SMS: run "T4B-Omnisend: Stop marketing texts" with the requester's email and the phone identifier from step 2 (E.164, like +15551234567). If step 2 shows no phone, use a number the customer wrote in the ticket; otherwise ask for it.
4. Email: run "T4B-Omnisend: Stop marketing email" with the requester's email.
5. If any Omnisend call fails, don't tell the customer anything has stopped. Add an internal note with the channel, the email, the phone and the error, tag the ticket "opt-out-manual", and reply that a teammate will process the request within one business day.
6. If it works, reply confirming exactly which messages will stop and that order and shipping updates still arrive, and tag the ticket "marketing-opt-out".
Hand off to a person, with what you found, for data deletion requests, "wrong number" messages and any request to sign back up.

The test ticket, #1130 on our d3v-macha Zendesk sandbox, is from "Nora Test" ([email protected]): stop the promo texts to +1 555 010 4477, "Emails are fine, I still read those." Our sandbox's webhooks don't reach the production agent, so we ran the agent from its chat with "Handle Zendesk ticket #1130."

The agent read the ticket and said, before any other call, that it would "stop SMS only and leave email subscribed". It got that from "Emails are fine", with no keyword to match. It called Find contact with Nora's email, Omnisend returned 401, and the tool panel marked the call "Failed, no change made". It never called either Write tool, which is right: with no contact record there was nothing to change.

It then followed step 5. It drafted an internal note (channel requested: SMS only; the email; the phone; the 401; "customer asked to stop promo texts only and explicitly said email is fine"), the tag opt-out-manual, and a public reply saying a teammate would process the SMS request within one business day and that her email subscription would be left as it is. The first write, the built-in Zendesk Add internal note tool, stopped on a confirmation card, and the tag and reply waited behind it. We didn't confirm, so nothing reached the sandbox ticket.

One flaw showed up. The note listed the phone as "+1 555 010 4477", with spaces, under a heading that said it had been normalized. Omnisend wants E.164 (+15550104477), so a teammate copying that value into a tool, or an agent passing it on the next run, would likely have the value rejected, since Omnisend identifies phones in E.164. The instruction's step 3 asked for E.164, but only for the tool call; a line saying "write phone numbers in E.164 everywhere, including notes" would close it. And the reply's "within one business day" is our instruction's promise, well inside the FCC's ten business days, which is the reason to write that number into the instruction rather than let the model pick one.

Where does Macha fit?

Macha fits teams already running Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom whose opt-out requests arrive by email and chat as well as by text, and who run one of the 8 marketing apps with a usable API. Macha's team builds the lookup and opt-out tools during onboarding, next to the built-in Shopify connector for the order questions that make up most of the queue; the Shopify apps hub maps the rest of the stack. Pricing is per ticket, from $299/month for 750 tickets, with setup and monitoring by the Macha team, included on every plan, so a store handling 750 tickets a month pays the same whether 20 of them are opt-outs or 200; the pricing page has the tiers. If your consent lives in Shopify Messaging or Seguno, an agent can acknowledge and route those requests today, but it can't change the consent itself.

To see how it handles your own opt-out tickets, start a trial with $50 of free usage (about 125 tickets), no credit card, no time limit.

Frequently asked questions

Does an email saying "stop texting me" count as an SMS opt-out? Under 47 CFR 64.1200(a)(11), an email to an address intended to reach the sender creates a rebuttable presumption that the consumer revoked consent. Paragraph (a)(10) requires revocations to be honored within ten business days, so the request has to reach the SMS platform, not just the support queue.

Which email and SMS apps have an unsubscribe API an AI agent can use? Of the 14 we checked, Klaviyo, Attentive, Postscript, Omnisend, Privy, Mailchimp, Recart and Drip document an opt-out call that works with a static key. Postscript limits custom API access to enterprise plans, Privy's API needs a paid account, and Recart issues keys through its support team.

Can the Postscript API unsubscribe someone by email address? Not directly. The unsubscribe endpoint accepts a phone number or a Postscript subscriber ID. An agent can find the subscriber ID first with GET /api/v2/subscribers?email__eq=, then unsubscribe by ID.

Does deleting a Mailchimp contact through the API unsubscribe them? No. The DELETE method on a list member archives it. To unsubscribe, PATCH the member with status set to unsubscribed. The separate delete-permanent action erases the member's data and blocks re-importing them.

Can an AI agent unsubscribe a shopper from Shopify Email (Shopify Messaging)? Not through Macha today. Shopify Messaging stores consent on the Shopify customer, and Macha's built-in Shopify connector has no consent tool. Since 1 January 2026 new custom apps can't be created in the Shopify admin (existing ones keep working, and new ones go through Shopify's Dev Dashboard), and consent writes through either route aren't something we set up today. The agent should acknowledge the request and route it to someone with admin access.

Is Klaviyo, Attentive or Postscript a built-in Macha connector? No. Each connects through a custom API tool that Macha's team sets up during onboarding, using the app's own API key. To try Macha on your own tickets, start a trial with $50 of free usage (about 125 tickets), no credit card, no time limit.

How we researched this

We read each vendor's developer documentation on 28 September 2026: Privy's API reference (update and delete contact, tokens, rate limits) and its Gorgias integration page; Postscript's developer docs (access, authentication, Unsubscribe, Redact, Get Subscribers); Omnisend's API reference (authentication, contacts, rate limits); Mailchimp's list members reference and fundamentals; Drip's API reference; Recart's developer introduction, its unsubscribe and subscriber-lookup references, and its unsubscribe intent detection page; Shopify's consent mutations and changelog; Seguno's help center; smsbump.com; and Gorgias's Postscript integration docs. Klaviyo and Attentive endpoint details were read the same day for our Klaviyo and Attentive pages. Compliance text is from eCFR, 47 U.S.C. 227 and the FTC's CAN-SPAM guide. App Store ratings are from each app's Shopify App Store listing on 28 September 2026 (Sendlane from 25 September). "No public API found" means we searched the vendor's own developer and help documentation and found none; a private or partner API may exist. The TCPA figure is arithmetic on a synthetic case (12 texts x $500 = $6,000, trebled to $18,000), not legal advice. On 28 September 2026 we built three Omnisend custom tools and an inactive agent on our Macha Demo test org, pressed Run Test, and ran the agent in chat on a made-up ticket (#1130) created on our d3v-macha Zendesk sandbox. Every Omnisend call used a dummy key, so Omnisend answered HTTP 401 each time; we have no Omnisend account and never saw a successful response, and we didn't call any other vendor's API against a live account. The sandbox's webhooks don't reach the production agent, so the ticket and the chat run are separate captures of the same scenario, and we didn't confirm the agent's Write actions, so nothing was posted to the ticket. Nora, her email, her 555 number and every other shopper example are synthetic.