There are two ways to connect a back-in-stock app to Klaviyo, they produce different results, and most setup guides describe the weaker one. The choice is whether the app sends the alert itself and tells Klaviyo afterwards, or whether the app only reports the event and Klaviyo does the sending.
The two integrations, and which one you want
App sends, Klaviyo records
The app owns the email. Klaviyo receives the subscriber as a profile and perhaps an event, so you can segment on it later. Setup is close to instant.
What you get is a working alert and a list. What you do not get is the flow builder, your templates, your suppression list, or reporting that sits alongside the rest of your email programme. The alert goes out on the app's infrastructure with the app's deliverability.
App reports, Klaviyo sends
The app pushes an event — someone subscribed, and later, the product is back — and a Klaviyo flow triggered by that event sends the message.
This is the setup worth having, for four reasons that have nothing to do with design. Your sending reputation is one domain rather than two. Your suppression list is honoured, so someone who unsubscribed last week does not receive a restock email this week. Flow logic becomes available, which is the entire point of the exercise. And revenue attribution lands in the same reports as everything else, so the restock programme can be compared with your other flows rather than defended separately.
The failure to avoid
Turning on the Klaviyo flow while the app is still sending its own alert. Both fire, the customer gets two emails about one restock, and it is not obvious in either dashboard because each shows one send. Whenever you move to flow-driven sending, switch the app's own notification off first and confirm with a test subscription.
Getting the data model right
Everything you can build downstream depends on what arrives. At minimum you want an event carrying the product, the variant, and the date the person joined the list. Variant matters more than people expect: "back in stock" for a product where only the XL returned is a wasted send to everyone waiting on a medium, and a slightly annoying one.
Store the subscription date as a profile property as well as on the event. Segmenting by how long somebody has waited is the most useful thing you can do with this data and it is awkward to reconstruct later.
If you sell in several languages, pass the locale the customer was browsing in when they subscribed. Deciding the language at send time from an IP address gets it wrong for anyone travelling or using a VPN.
Consent, before the flows
A back-in-stock subscription is a request for one message about one product. It is not consent to a marketing programme, and in the EU and UK treating it as one is a compliance problem rather than a growth tactic. It is also a bad trade — the fastest way to lose a list of people who told you exactly what they want is to send them a newsletter they did not ask for.
Do it properly: sync waitlist subscribers to a profile with a property marking how they arrived, and add a separate, unticked marketing opt-in on the widget. Anyone who ticks it joins your marketing consent group and everything below is open to them. Anyone who does not gets the restock alert and nothing else, and that is the deal you offered.
Flows worth building
The stock-aware sequence
The standard advice is three emails: it's back, it's selling, last chance. The version that works adds a condition — check inventory before each follow-up and exit the flow if it has gone. A "last chance" email for a product that sold out yesterday is the one message in this sequence guaranteed to produce a complaint.
Space the follow-ups by how fast the item moves, not by a fixed 24 and 48 hours. A staple that sits for weeks does not need a scarcity email on day two.
The still-waiting email
If you notify in waves, the people in later waves are sitting in silence wondering whether they were forgotten. A short "it's back, you're in the queue, we'll email when your turn comes" costs nothing and prevents the support ticket. It is the highest-value message in this whole programme and almost nobody sends it.
VIP head start, with the cost stated
Segment the waitlist by lifetime value and notify the top group a few hours early. It works. It also means a customer who joined the list first and bought less gets the email second, which is a decision to make deliberately rather than to discover when someone complains. A few hours is defensible; a day is a different proposition.
The substitute flow
For someone who has been waiting more than a few weeks on an item with no restock date, a message suggesting two close alternatives recovers a sale that was otherwise going to expire. Trigger it on time-since-subscription, and exit it the moment the product returns.
The price-drop overlap
If you also capture price-drop subscribers, suppress restock alerts for anyone who is in an active price-drop flow for the same product. Two automated emails about one product in one day reads as a system talking to itself.
Segments that earn their keep
- Waiting more than 30 days — the substitute flow above, and a signal to look again at reordering.
- Waiting on more than one product — a materially more engaged group than single-item subscribers.
- Subscribed but never purchased — the group for whom the restock alert is a first-order opportunity, not a repeat one.
- Notified but did not buy — the honest test of whether your alert copy and timing work at all.
That last one is the segment most people never build and the one that tells you the most. If it is large, the problem is not the flow; it is that you are notifying more people than you have stock for.
What breaks when the two systems drift
The integration is not a one-time setup, and three things go wrong quietly months later.
A product gets deleted or its handle changes. The event still fires with an identifier Klaviyo cannot resolve, and the flow sends an email with a broken link or an empty product block. Nobody notices until a customer replies. Include the full product URL in the event payload rather than rebuilding it from a handle inside the template.
Someone edits the flow and removes the exit condition. The inventory check described above is one block in a flow that other people also edit. It is worth a comment in the flow name itself so the next person understands why it is there.
The app's own notification gets switched back on during a support conversation about something else, and duplicate sends resume. Subscribe a staff address to a low-traffic product and leave it there permanently; a restock on that product tells you immediately how many emails actually go out.
Reporting without double counting
Both the app and Klaviyo will claim revenue from a restock purchase, and if you add them together you will report a number that is roughly twice reality. Pick one system as the source of truth — if Klaviyo is sending, it should be Klaviyo — and read the app's figure as a sanity check rather than an addition.
Set the attribution window deliberately, too. A five-day window on a restock email will capture purchases the customer would have made anyway, having already decided weeks ago. A short window understates it. There is no correct answer, only a consistent one.
Where to go next
Stok pushes subscription and restock events to Klaviyo so the sending can live in your flows rather than in the app. For the send-sizing decision that sits underneath all of these flows, see more people waiting than stock, and price drop alerts for the other event worth wiring into the same flows.
