What Shopify Bot Signups Did to Our Klaviyo Bill

You enabled Google reCAPTCHA in Online Store > Preferences months ago. You turned on double opt-in in Klaviyo. You added a honeypot field to the signup form. You watched a tutorial about Shopify Flow and built a rule that deletes any new customer record whose display name contains an "@" symbol. Your customer list still gained two thousand fake accounts in twelve weeks, your Klaviyo bill jumped a tier, and you cannot work out which of those fixes is supposedly catching the shopify bot signups.

We had a merchant in this exact spot a few weeks ago. Here is what happened, what we missed, and what eventually moved the number.

What happened

The merchant was a solo founder on Shopify Basic doing about $14k a month in digital downloads. Klaviyo was sitting at the 1,500-contact tier, billed at around $45 a month. On a Monday in April, the bill posted at $115. Klaviyo's profile counter said 4,800 contacts.

Forty-eight hours of frantic exporting later, the pattern was unmistakable. Roughly 3,100 new customer accounts had been created in twelve weeks, almost all with no orders. The user agent was okhttp/5.3.2. The display names were fifteen repeating pairs ("Emma Smith," "Alexander Rodriguez," "James Bond") cycled across Gmail, Outlook, Hotmail, Yahoo, and iCloud addresses. The same fingerprint a Shopify Community thread had been documenting since April 2026, where one merchant reported 2,066 accounts accounting for 56% of their entire customer database. Shopify engineering had confirmed the signature affected multiple stores and declined to block it at the platform level.

The thing we did not realise at the time: shopify bot signups reach a Klaviyo profile through more than one path. We had been watching the wrong one.

Why our usual checks did not catch it

Three defenses were "on": reCAPTCHA at account creation, Klaviyo double opt-in, a Flow rule that deleted any signup whose display name equalled its email address. None of them touched what was actually happening.

The okhttp wave does not submit the frontend form. It calls /account/register directly. reCAPTCHA, which lives on the rendered HTML form, never gets a chance to challenge it. The Flow rule fired correctly when a display name was the email address, but the okhttp script was politely supplying first and last names, so the rule passed every record through.

Double opt-in is a real defense, but only against the form path. Klaviyo's industry specialist has confirmed in their community that every time a checkout started event happens, Shopify sends Klaviyo the profile regardless of signup. Bots that initiate a fake cart with the /cart/{variant_id}:{quantity} URL scheme generate a Klaviyo profile per fake cart, with no opt-in required and no consent event needed. We had not even looked at the checkout side, because no orders were ever placed. That was the blind spot, and it is the part of shopify bot signups that catches even merchants who think they have already done the work.

What we tried that did nothing

The first thing we tried, which is the first thing most merchants try, was a third-party bot protection app. The app blocked a small number of frontend submissions. It did nothing to the API path. The bot kept creating accounts.

Cloudflare rate-limiting on the merchant's primary domain caught nothing for the same reason a community member documented in an April 2026 r/shopify thread: bots hit the *.myshopify.com subdomain that Shopify itself routes, not the merchant's CDN. The Cloudflare rules never see the traffic.

We also disabled the abandoned-cart flow in Klaviyo for two days, hoping to slow the deliverability damage. That stopped emails landing in spam boxes belonging to real people whose addresses the bot had borrowed. It also meant a few real customers did not get their cart-recovery email, which we are still slightly annoyed about. If we were doing it again we would have segmented out only the suspicious profile pattern instead of disabling the flow wholesale.

What actually moved the number

Three changes, in this order:

1. A bulk delete via the Admin API. Shopify's admin UI has no batch delete for customers. We pulled all customers created in the affected window, filtered for okhttp/5.3.2 and the matching name pairs, and ran DELETE /admin/api/2024-01/customers/{id}.json in batches of one hundred with a brief sleep between batches. Roughly 2,800 records gone in an afternoon.

2. Switched the store to New Customer Accounts. Settings > Customer accounts. The new system requires email verification with a one-time passcode before login. It does not stop the account record being created on the registration endpoint, but it prevents the bot from ever completing a login flow. More importantly, it gave us a cleaner audit signal: accounts that never verify can be auto-pruned without ambiguity. The URL structure for login and password reset changes when you switch, so test those flows on a draft theme first.

3. Restricted Klaviyo's profile creation from Shopify events. We opened a Klaviyo support ticket asking specifically: can we disable profile creation from the Checkout Started event? The answer was yes, with a caveat that it would reduce some real abandoned-cart attribution. We accepted that tradeoff. The next billing cycle dropped one tier and the count of new shopify bot signups landing in Klaviyo dropped to near zero.

The merchant still pays slightly more than the pre-attack baseline. Some of the okhttp profiles that got synced to Klaviyo before we caught it are now suppressed but still counted. Klaviyo's billing treats suppressed and deleted profiles differently, and we have not had a clear answer on whether bulk-deleting the suppressed contacts will lower the bill or just remove the data. If you have a recent answer to that one, the first fifteen minutes with a help1 expert is free and we would happily compare notes. We are still piecing this part together.

The check we now run every Monday

Once a week the merchant exports the customer list filtered to "created in the last 7 days, zero orders." If the number is above 50, we open the user agent column. If okhttp is there, we run the bulk delete script again. If a name pair repeats from the known list, we add it to the Flow rule. It takes about ten minutes.

A flagged customer-count delta is also one of the early signals our store scan watches for, because by the time a wave of shopify bot signups shows up on a Klaviyo invoice the bill has already posted. We built that detection partly because we got tired of being the person who told a merchant their bill jumped two weeks after the bill jumped.

If we had been running this check the week the okhttp wave started, we would have caught it in twelve hours instead of twelve weeks. We were not running it, because the signs are quiet. A few hundred extra accounts a day is unusual for a $14k store but well within the range that an ordinary spike-hunter skims past.

A Klaviyo bill is the slowest possible way to learn that bots have been opening accounts on your store since February.