The one auth bug that blocked my Shopify app for weeks
I just shipped my first Shopify app. Getting it approved took longer than building it, mostly because of one auth issue I couldn't find documented anywhere.
Shopify embedded apps run inside an iframe in the admin. Session tokens work differently there — they don't persist the way cookies do when you navigate between routes. Every sub-route was returning 403, randomly, with no clear error message. The index route loaded fine. Everything else failed.
I spent days reinstalling the app, clearing sessions, changing scopes. Nothing worked consistently.
The fix was two lines:
First — redirect must come from authenticate.admin(request), not from React Router. They look identical in code but behave completely differently inside an iframe context.
Second — authenticate.admin must be the very first call in every loader and action, before anything else including your own database queries.
That's it. The kind of thing that takes five seconds to fix once you know it, and days to find.
The app is a business health monitor for Shopify merchants — RFM customer segmentation, inventory velocity alerts, profit tracking. Just launched with 1 install so far. If you're building on Shopify and hit similar auth issues, happy to compare notes. And if you're a Shopify merchant curious about the analytics angle, feedback is very welcome.
https://apps.shopify.com/virtevo-pulse
Congrats on shipping — that iframe/session token behavior is genuinely underdocumented. I hit something adjacent recently: Shopify's move to expiring session tokens with automatic refresh caught a few edge cases I hadn't anticipated, mostly around routes that assumed a stable session across the whole request lifecycle. Different root cause than yours, same category of pain — the embedded admin context breaks a lot of assumptions that work fine outside an iframe.
Also at "1 install" stage myself with a Shopify reporting app, so curious about your inventory velocity alerts specifically — how are you deciding what counts as a real signal vs. normal noise? That's the part I've found hardest to get right with revenue drop alerts on my end: too sensitive and merchants tune it out, too conservative and it misses the thing they actually needed to know about.
The session token expiry edge cases are real — I'm still not confident I've caught all of them.
On inventory velocity: right now I'm keeping it simple. Days of stock remaining = current inventory / average daily sales over 30 days. Alert threshold is 7 days for critical, 14 for warning. No dynamic adjustment yet.
The noise problem you're describing is exactly what I haven't solved. A product that sells 2 units a day normally looks critical when it drops to 0 for a week — but that might just be a slow week. I'm not doing any seasonality correction or baseline smoothing at this point.
Curious how you're handling it on the revenue side. Are you using a rolling average as baseline, or something more sophisticated?
I like that you shared the auth lesson, but what caught my attention was the product itself.
Most analytics tools tell merchants what already happened. A business health monitor has the opportunity to become something different—helping them notice issues early enough to act before they show up in the monthly numbers. That feels like a much stronger problem to own.
That's exactly the angle I'm trying to own. The name "Pulse" is intentional — something you check daily, not a dashboard you open after something already went wrong.
The RFM segmentation is the clearest example right now. Instead of showing a customer list, it tells you which customers are going quiet before they're actually gone. That's the window to act.
Appreciate the framing — it's a cleaner way to describe what this actually is.
Interesting.
Reading your reply made me think less about early detection itself and more about what a business quietly commits to once it promises to help people act before problems become visible.
I don't think I can explain that line of reasoning properly in a thread without oversimplifying it.
If you're open to it, what's the best email to reach you on?
Sure — hello@virtevo.bg
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.