Integration
reOtter + Skio: Replenishment That Knows Who's Subscribed
A read-only integration. reOtter reads your Skio account for the ground truth on subscriptions: who's actively subscribed, to which products, and when each subscription starts and ends. It never creates, edits, or cancels anything in Skio. reOtter uses that truth to exclude active subscribers from reorder reminders on their subscribed products and to time at-risk and winback triggers from real end dates instead of inferred ones.
What reOtter + Skio does
Skio is the system of record for your subscriptions. reOtter is the engine timing reorders for everyone who isn't subscribed. The integration gives reOtter read-only access to Skio so it always knows, explicitly, which customers are which: who holds an active subscription, which products it covers, and when it starts and ends.
reOtter uses that knowledge to do less, more precisely. A customer with an active Skio subscription to a product never gets a reOtter reorder reminder for that product — no "running low?" text about the bag that ships automatically. And when a subscription ends, reOtter knows the exact date, so its at-risk and winback triggers fire from reality instead of a reconstructed guess.
Read-only, by design
The integration has no write path into Skio. reOtter cannot — not "does not," cannot — create a subscription, change one, pause one, or cancel one. Your Skio checkout, customer portal, retention flows, and passwordless login all keep working exactly as they do today, untouched.
That's deliberate. reOtter's position is that replenishment and subscriptions are two layers serving two different kinds of customers, and layers only coexist cleanly when the boundaries are enforced. Read-only access is the enforcement: reOtter can see the boundary perfectly and can't cross it.
What reOtter reads from Skio
- Active subscriber status — which of your customers currently hold a Skio subscription.
- Subscribed products — the exact products and variants each subscription covers, so suppression is per-product, not per-customer.
- Start and end dates — when each subscription began and when it ended or was canceled, as recorded by Skio.
The per-product detail matters. A customer might subscribe to your best-seller through Skio and still buy two other SKUs one-off. reOtter suppresses reminders on the subscribed product and keeps running normal replenishment timing on the rest.
Inference vs. ground truth
Before this integration, reOtter identified subscribers the only way it could: by recognizing subscription-shaped patterns in Shopify order history. Orders recurring at machine-regular intervals were treated as likely subscriptions and handled carefully.
That inference was good, not perfect. Edge cases — a brand-new subscription with only one order behind it, an irregular gifting pattern that looks recurring, a cancellation that hasn't shown up as a gap yet — are exactly where inference wobbles. The Skio sync removes the wobble: subscription starts show up when they start, not after enough orders accumulate to reveal a pattern, and cancellations show up when they happen, not after a suspicious silence.
What it means for your triggers
- Reorder Reminders — excluded for actively subscribed products, with certainty. Subscribers stop being a false-positive risk the day the integration connects.
- At Risk & Winback — a canceled Skio subscriber re-enters reOtter's lifecycle with a known end date. The winback engine times its outreach from when the subscription actually stopped, which is precisely the moment that customer's replenishment coverage went away.
- The whole engine — customer-level accuracy compounds. Knowing definitively who's covered by a subscription cleans up cohort timing for everyone else too, because subscription orders stop polluting the reorder-cadence math.
Two layers, one clean boundary
Skio captures the customers ready to commit; reOtter works the repeat buyers who want to stay one-time. The integration doesn't blur that line — it draws it in ink. Skio owns its subscribers completely, and reOtter can prove it's leaving them alone.
Connect reOtter to your stack → Install reOtter free
Frequently asked questions
- Is reOtter an alternative to Skio?
- No — different job entirely. Skio is your subscription platform; reOtter is a replenishment engine for the repeat buyers who don't subscribe. The integration is read-only, so reOtter physically can't compete with, replace, or modify anything in Skio. It reads subscription status and uses it to stay out of Skio's lane.
- What access does reOtter have to my Skio account?
- Read-only. reOtter reads who your active subscribers are, which products their subscriptions cover, and when each subscription starts and ends. It cannot create, edit, pause, or cancel a subscription — there is no write path.
- Will Skio subscribers keep getting reorder reminders from reOtter?
- No — that's the main point of the integration. An active Skio subscription to a product excludes that customer from reorder reminders for that product. They can still get replenishment messages for other products they buy one-off.
- How did reOtter handle Skio subscribers before this integration?
- By inference. reOtter detected subscription-like recurring patterns in Shopify order history and treated those customers accordingly. That caught most cases; the integration replaces the guess with Skio's actual records, including exact start and end dates.
- Does the integration help with churned subscribers?
- Yes. When a Skio subscription ends, reOtter knows the exact date — so at-risk and winback triggers time themselves from when coverage really stopped. A churned subscriber becomes a precisely-timed winback candidate instead of a guess.
- Do I need both a messaging integration and the Skio integration?
- They do different jobs. Klaviyo, Attentive, Postscript, or Omnisend is where reOtter sends trigger events — the messaging layer. Skio is a data source that makes those triggers more accurate. Most brands running Skio connect both.