The request
Written at the moment of asking. In your Klaviyo account this is the metric named Back in Stock Request, and it is the one to look at if you want the demand signal rather than the send.
Integrations · Back-in-stock
A shopper asks for the shade you are out of. That is the most useful question in a conversation and the one most assistants waste, because the honest answer — not today — ends it. Refik can instead take an email address at that moment and write it to your Klaviyo account, then write a second event when that exact variant comes back. The division of labour matters and it is the whole point of this page: Refik records what happened, and the message that reaches your customer is sent by a flow in your own account, with your sender, your wording and your unsubscribe handling.
The two events
The first event is the sign-up, written the moment a shopper gives an address, so you can see demand for something you are not currently selling. The second is the arrival, written when the variant they asked about is in stock again, and that is the one your flow listens for. Keeping them separate means the request is useful on its own: a variant that never comes back still leaves you a record of how many people wanted it.
Written at the moment of asking. In your Klaviyo account this is the metric named Back in Stock Request, and it is the one to look at if you want the demand signal rather than the send.
Written when that variant is available again. The metric is Back in Stock, and this is the trigger your flow should be built on.
Refik does not create the flow. If no live flow listens for this metric, the event is still written and nothing is sent — which is a quieter failure than it sounds, so it is worth checking once.
The exact variant
Waiting on the product would be easier to build and worse to receive. A shopper who wanted the black one in medium does not want to be told the product is back because the white extra-large arrived; that email is the reason people stop trusting back-in-stock notices. Refik keeps the request against the specific variant and the arrival event is written for that variant alone.
A pending request is kept for up to 180 days and then expires. Six months is long enough to cover a seasonal restock and short enough that nobody receives a message about a question they asked a year and a half ago.
Each variant holds up to 500 pending requests. That ceiling exists so that one very popular variant cannot grow without limit, and reaching it is information: it means demand well past the point where the answer is an email.
Restocks are noticed on a schedule rather than at the instant of a stock change, and a single run notifies up to 200 waiting shoppers. A larger backlog finishes across consecutive runs instead of being sent as one burst, which also keeps a restock from arriving in your customers’ inboxes as a spike.
The address a shopper gives is validated before anything is written, so a typo is rejected at the point of asking rather than becoming a bounce in your account later.
What you configure
You paste your Klaviyo site ID into the console and save. That identifier is public by design — it is the same one your own storefront scripts carry — and it is the only Klaviyo value Refik holds. No private API key is asked for and none is stored, which means there is no Klaviyo credential of yours sitting in our infrastructure to be rotated, leaked or audited.
There is no default account, no shared list and no silent fallback. Until the field has a value the assistant does not offer to take an address at all, so the feature cannot be half-on: either the events have somewhere of yours to go, or the offer is not made.
Clearing the field turns it back off, and nothing of yours is kept on our side for that store beyond the pending requests already recorded, which expire on their own.
Klaviyo exposes a client-side path that accepts only the public site identifier, and that is what Refik uses. The alternative — a private key with broader permissions — would let us do more and would also mean a secret of yours in a system you cannot inspect. The narrower path was the right trade, and it is also the reason some things on this page are not possible.
It cannot read your lists, your profiles, your segments or your campaign results, and it cannot create or edit a flow. The public path writes events; it does not grant access to your account. Anything on this site that describes Klaviyo behaviour is therefore describing what Refik writes, never what it has seen.
The shopper’s address
The address a shopper types is written to your Klaviyo account and held against the pending request until the variant returns or the request expires. It is given voluntarily, in response to an explicit offer, for a stated purpose. What happens to it after it reaches Klaviyo is governed by your account and your own privacy notice, not by ours — which is the ordinary consequence of the email being yours to send.
The deletion paths, including what happens to a pending request when a shopper asks to be removed or when a store uninstalls, are written down rather than summarised here.
The limits of this page
Refik can tell you that it wrote an event. It cannot tell you that a message was delivered, opened or acted on, because it never sees your flow. If your flow is paused, misconfigured or listening for a different metric, the events accumulate and nothing reaches anyone — and the only place that becomes visible is your own Klaviyo account.
Not here, and not claimed: any other email or SMS provider, a back-in-stock notice sent by Refik itself, a recovery rate or conversion figure for restock emails, and anything about how this behaves at a volume we have not run. Email notifications in general are a separate line on the integrations page with its own status, and it is not this one.