Retailers have spent years perfecting their online personalization: abandoned cart emails, back‑in‑stock alerts, smart product recommendations, and post‑purchase review flows. But for many store‑first businesses, what happens in the showroom is still largely invisible to their marketing tools.
Our team specializes in building custom solutions on top of the STORIS retail platform. Recently, we designed and implemented a robust integration between STORIS and Klaviyo that closes this gap. By leveraging STORIS webhooks, a purpose‑built middleware layer, and Klaviyo’s event API, we now send rich, in‑store activity into Klaviyo in near real time.
The result: in‑store experiences can now trigger the same kind of personalized, automated marketing flows that customers expect from ecommerce.
Business Goal: Give In‑Store Customers the Same Personalization as Online Shoppers
The core question we set out to answer was simple:
“If a customer walks into a store, gets a quote, places an order, or picks up their purchase, why shouldn’t that activity power the same smart emails and journeys that an online checkout does?”
STORIS already knows everything about those in‑store interactions: quotes, written orders, fulfillment details, locations, salespeople, and more. Klaviyo, on the other hand, is excellent at turningeventsinto targeted campaigns and flows.
Our job was to build the bridge between them in a way that is:
Reliable – events can be trusted and replayed if needed.
Marketing‑friendly – data is structured for segmenting and templating, not just for engineers.
Extensible – new retailers or event types can be added with minimal rework.
High‑Level Architecture: Webhooks + Middleware + Klaviyo
At a high level, the integration looks like this:
STORIS webhooks fire when something happens in the store (a quote is written, an order is created, a fulfillment is completed, etc.).
Our middleware receives these webhooks at dedicated endpoints, validates and enriches the data, and translates it into Klaviyo‑friendly payloads.
Klaviyo receives events via its Create Event API and updates or creates customer profiles, triggering flows and campaigns.
We implemented this pattern for multiple retailers and environments, so the middleware is designed to be configurable: each STORIS account and site can subscribe to a set of events, and those events are standardized before they ever reach Klaviyo.
The Key Moments We Capture from STORIS
For marketers, the most valuable signals tend to be the ones closest to the customer’s decision‑making. We focused on four primary categories of events:
1. Quotes → Klaviyo “Received Quote” Events
When a salesperson creates a quote in STORIS, STORIS fires an OrderWrittenQuote webhook. Our middleware listens for this and transforms it into a Klaviyo event we call “Received Quote”.
That event includes:
Where it happened – store location ID and description (e.g., a specific showroom).
What’s in the quote – product names, grouped collections and product groups, item counts, and quantities.
Who it’s for – the customer’s email or phone plus identifiers like a STORIS customer ID.
Digital‑commerce context – when items link to ecommerce products, we can generate a cart link that lets the customer revisit the quote online.
Marketers can then build flows such as:
“You left the store with a quote – here it is in your inbox.”
Follow‑up reminders if the quote isn’t converted after a certain number of days.
Targeted offers based on collections or brands present in the quote.
2. Orders → “Completed Purchase” + “Purchased Product” Events
When a quote becomes an order, STORIS emits an OrderWrittenSale webhook. For each order we send two types of events into Klaviyo:
“Completed Purchase”– one event per order, summarizing total value, currency, store location, and high‑level product groupings.
“Purchased Product”– one event per line item, with SKU‑level details: product name, brand, category, collections, quantity, and line total.
This mirrors how ecommerce platforms often report data, and it unlocks a lot of flexibility:
Order‑level flows (receipts, post‑purchase nurtures) can use Completed Purchase.
Product‑specific flows (review requests, warranties, accessories upsells) can key off each Purchased Product.
Whenever possible, we enrich these events with ecommerce data: product URLs, images, and even direct review links using Klaviyo’s reviews app URL patterns. That lets a customer click directly from an email into a review screen for the exact product they bought.
3. Fulfillments → “Fulfillment Completed” Events
The moment a customer actually receives their furniture—whether by delivery, customer pickup, direct ship, or “take with” from the store—is an ideal time to communicate. STORIS emits different fulfillment webhooks, which we normalize into Klaviyo “Fulfillment Completed” events.
For each fulfillment type we include:
Fulfillment method (Pickup, Delivery, Direct Ship, Take With) and status (Scheduled, Complete, etc.).
Store and route details – location, route codes, delivery dates.
Per‑item details – names, quantities, related ecommerce products when available, and review URLs.
Tracking information (for deliveries) – tracking number, carrier, and tracking URL, plus a convenient
containsTrackingNumberflag so emails can show tracking info only when it exists.
From a marketing and service perspective, this supports flows like:
“Your order has been delivered — here’s your tracking and care instructions.”
“How’s your new patio set? We’d love your feedback.”
Cross‑sell campaigns based on the specific items or collections fulfilled.
4. Unsubscribes → Synced Back to STORIS
Permission management is critical when bridging in‑store and online systems. If a customer unsubscribes from email marketing inside Klaviyo, we don’t want them to be accidentally opted back in at their next in‑store visit.
To solve this, we also listen to Klaviyo Flow Webhooks tied to the “Unsubscribed from Email Marketing” event. When this fires, Klaviyo calls our middleware with:
The customer’s email and, where available, their STORIS customer ID.
A header indicating the action (e.g.,
customer/unsubscribe).
Our middleware validates the webhook with a shared secret and then updates the corresponding STORIS customer record to mark them as not okay to solicit. That way, consent stays consistent in both directions.
Making the Data Marketing‑Friendly (Not Just Technically Correct)
Capturing events is only half the battle. To be truly useful for marketers, the data needs to be structured in a way that makes segmentation and email templating straightforward.
Designing Events for Segmentation
As we designed the payloads sent to Klaviyo, we followed a few guiding principles:
Use clear, flat properties for anything marketers might want to filter or group on: store IDs, collections, product groups, salespeople, fulfillment methods, and so on.
Use arrays (lists of values) instead of single strings for fields like store IDs, locations, collections, groups, and route codes. This makes it easy to build segments like “customers whose purchases include any of these locations or collections.”
Deduplicate those arrays so marketers don’t see confusing duplicates in their UI.
Standardize date formats so Klaviyo recognizes them as dates, not plain numbers, making them usable in time‑based filters and flows.
We also distinguish between:
itemCount – the number of distinct line items.
totalItemQuantity – the total quantity across those items.
This small nuance enables more accurate reporting (for example, a quote with 2 of Chair A and 2 of Chair B is 2 items but 4 units).
Connecting In‑Store Products to Ecommerce
Many of our clients sell both in‑store and online. Whenever a STORIS product is also sold via their ecommerce platform, we try to link the two worlds:
If an item can be matched to an online product, we include its product URL, image URL, and a review URL specific to that product and retailer.
If not, we still send a clear human‑readable name and any merchandising data available from STORIS so emails stay understandable.
This makes emails feel coherent regardless of channel: a customer sees the same product name and image they recognize from in‑store displays or the website.
Handling Real‑World Complexities: “Soft Kits”
One interesting challenge came from how STORIS represents certain bundled products. A patio “kit” might be made up of separate components—two chairs, a table, cushions—each as its own line item linked together by a shared kit identifier.
For warehouse and inventory teams, that level of detail is useful. For marketing and customers, though, it’s often clearer to see a single “Patio Set” line item, not four separate parts.
We implemented soft kit collapsing logic in our webhook consumer:
Detect component line items that belong to the same kit.
Determine how many complete kits can be assembled from the components.
Replace those individual components with a single synthetic “kit” line in the Klaviyo payload, with correct quantities and pricing.
Preserve any leftover components that don’t form a full kit so totals still match what’s in STORIS.
We also built a comprehensive test suite around this behavior to ensure kit collapsing is accurate and backward‑compatible. The payoff is that customers and marketers see the product the way it’s actually merchandised.
Operational Learnings: Reliability Matters
Integrations like this live at the intersection of several systems: STORIS, our middleware, Klaviyo, and often an ecommerce platform. Along the way, we encountered and solved a number of operational challenges that are helpful to keep in mind for any similar project.
1. Webhooks Must Be Explicitly Enabled
On more than one account, our initial attempts to subscribe to STORIS webhooks surfaced errors indicating that “events are not enabled.” In practice, that meant:
Working with STORIS support and the retailer’s internal team to ensure webhooks were actually turned on for the live account.
Re‑running our subscription setup scripts to confirm that webhooks were created and active.
Lesson learned: treat webhook enablement as a checklist item during onboarding, not an assumption.
2. Be Ready for Backlogs and Outages
We also saw cases where no webhooks arrived for several days, then hundreds landed within a short window once an upstream issue cleared. Because our middleware is stateless and idempotent, it was able to process that backlog without duplicating events or overloading Klaviyo.
Similarly, when we noticed no events hitting our middleware for a new retailer, we used:
Manual test requests to confirm our endpoint was healthy.
STORIS webhook history tools and vendor communication to identify and resolve upstream issues.
3. Permissions and API Details Matter
On the Klaviyo side, certain operations—like subscribing a profile to a list during a purchase event—require specific API permissions. In one instance, missing permissions meant subscriptions quietly failed until we updated the API key configuration.
The takeaway: treat API permissions as part of deployment, not just configuration, and log responses clearly so problems surface quickly.
4. Defensive Design for External APIs
When integrating tightly with vendor APIs, documentation doesn’t always match reality. For example, an endpoint might be documented to return structured error details but instead send back an empty response on failure.
We built in:
Clear logging of request and response metadata (without exposing sensitive data).
Fallback and retry behavior where safe.
Manual tools (like Postman collections and console commands) to validate behavior outside of the application when needed.
What This Unlocks for Retailers
Once the plumbing is in place, the impact on marketing teams is significant. Some of the concrete benefits we’ve seen or enabled include:
Unified customer view – in‑store quotes, orders, and fulfillments appear alongside online behavior in Klaviyo profiles.
Smarter segmentation – filter by store location, collections, product groups, fulfillment method, salespeople, and more.
Richer post‑purchase experiences – send tailored care guides, upsells, and review requests based on exactly what the customer bought and how they received it.
Consistent consent – unsubscribe preferences are honored across both in‑store and email channels.
Future‑proofing – as STORIS or Klaviyo evolve, the middleware can adapt without forcing major changes to marketing flows.
Conclusion: Turning Operational Data into Customer Experience
On their own, STORIS and Klaviyo are powerful systems. STORIS excels at managing complex, in‑store retail operations; Klaviyo shines at turning customer data into timely, relevant communications.
By integrating them through a carefully designed webhook middleware, we’ve helped retailers turn everyday operational events—quotes, orders, fulfillments, and even unsubscribes — into a continuous, personalized conversation with their customers.
If you’re using STORIS and want to bring online‑level personalization into your showrooms, or if you’re considering Klaviyo as a marketing engine for your in‑store data, we’d be happy to explore what this kind of integration could look like for your business.