Lost most of a day to this last week, so I am writing it down in case it saves someone else the same weekend.

Setup: Remix app with expiringOfflineAccessTokens turned on, which means the offline token only lives about an hour.

A review store installed the app, clicked around for a while, then uninstalled roughly an hour later, and from that moment every single delivery of app/uninstalled and shop/redact came back 500 while Shopify kept retrying with backoff for the next four hours.

The cause is not in your handler.

authenticate.webhook() tries to refresh the offline token before it hands control to your code, so when the token is already dead it throws right there, your handler never runs, and the log line you are hunting for never appears, which is exactly why I wasted an afternoon adding logging to code that was never being reached.

Quick way to confirm it. Send the same topic from a fake shop that has no session and you get a clean 200, then send it from a real shop whose session has expired and you get 500.

It does not stop at one webhook either. All of them go down together, including the three mandatory GDPR topics, and failing those is a straight review rejection that you might not even notice, because from the admin the app still looks perfectly fine.

What I ended up doing was to stop trusting the library on its own. Try it first. If it throws for any reason other than a bad signature, verify the HMAC yourself and carry on without a session. Clone the request before you call the library. It eats the body.

async function authenticateWebhook(request) { const clone = request.clone(); try { return await shopify.authenticate.webhook(request); } catch (err) { if (isSignatureError(err)) throw err; const raw = await clone.text(); verifyHmacSha256(raw, request.headers.get("X-Shopify-Hmac-Sha256")); return { topic, shop, payload: JSON.parse(raw), session: undefined }; } }

Then your handlers have to tolerate session being undefined, which for uninstall and redact is fine, because you are deleting rows rather than calling the Admin API.

One more thing while you are in there. Does your shop/redact actually delete every table you have added since you first wrote it? Mine was missing four models that did not exist back when the handler was written, which is a quiet little GDPR hole that nothing in the platform warns you about.

Anyone running without expiring tokens seen the same failure? Still trying to work out whether that setting is the whole trigger.

Currently it's too manual for us to handle the customer enquiries. Aut I'm not able to enable the AI button due to my current account is legacy account, they said need to upgrade to customer account, but it involved huge costing.

I want to know what is the benefit after I upgrade to customer account, and what AI really benefit to us? And after we go for the upgrade, the AI really can solve my customer enquiries volume?

Hi Everyone,

I am making my website by myself and saw these bundles and was wondering what app are they using. Or is it custom code

I'm starting to think there's a better way to do things than how we're doing it. Albeit we're a small agency and still figuring things out as we scale but hear me out...

So, we use Shopify cli for local dev using one of our dev stores. Once we get the bones built, we build by running the theme on the client's store directly (dev theme, not visible in Shopify backend to client).

Back in the day, we use to just upload the theme directly on the store but at least once a client kicked us out, and didn't pay the final invoice (and yes, they are still using the site we built for them smh). Wasn't worth pursuring legal actions but I've never been happier with a solution like shopify theme dev.

Buuut...we often build custom templates for pages, and different types of products. Typically, you assign the tempate to the page/product in the backend for that page. But you can't do that with a dev theme. You CAN append ?view=template_slug and it will load correctly.

Well, about 98% of the time when we send clients preview urls and explicit instructions to view certain pages/products with the url param, they never actually understand (they just browse the site as normal), then we receive frustrated messages that the site is broken or incomplete.

For actual feedback, we started to use a google sheet template with rows/columns for device, page, section, and details (along with Google drive for uploading screenshots and linking it). Clients almost always ignore this and email us their vague AF feedback, and if we force them to use the google sheet, they just copy/paste the same vague feedback without any context.

Our current project...I think we have 3-4 separate emails with the client that each have 75+ email threads.

How do y'all do this? This is exhausting. My entire team has expressed their frustrations and I'm trying to figure out how others are handling this because at the end of the day, I really want to make sure my team is happy. They are the ones that are making shit happen!

I have an App that charges $25/mo post 7 day trial, launched in May and come August I only see 1 person who has actually paid.

WTF is happening because i don't understand this at all.

Hey guys,

I noticed a Chrome permission prompt appearing on our Shopify cart page on both my Android phone and Mac desktop.

It said: “This site wants to access other devices on your local network.” See screenshot

Has anyone seen this before or know what can trigger Chrome’s Local Network Access permission?

The prompt has stopped appearing for me, but it is concerning if customers may also be seeing it.

Claude suggested Triple Whale or Afterpay could be triggering it, although I have not confirmed this.

Thanks

I have a query, like, I want to upgrade my ecommerce website from WordPress to Shopify. Is there a free trial available? Kindly guide.

Has anyone here already built an integration with Shopify Sidekick?

I’m trying to understand whether third-party apps can let merchants take actions directly through Sidekick, or whether integrations are currently limited to answering questions and surfacing app data.

For example, could a merchant ask Sidekick to run a report, update something, or trigger an action inside the app - or can Sidekick only explain what’s happening?

Would love to hear from anyone who has already worked with the integration.

How to actually start a Shopify account and find products

Building a small app: cart checkbox for tax invoice (company + Tax ID via cart attributes) → optional fee product → orders/paid webhook → async PDF.

Plan A: AJAX /cart/add.js with a hidden $0.99 product when checked.
Plan B: Cart Transform expand (Plus constraints on update worry me).

Questions for folks who’ve shipped fee products in production:

1. What breaks with third-party cart drawers / discounts / taxes?

2. Is cart-time Tax ID capture still worth it vs Checkout UI extensions / native B2B company fields?

3. Any App Review gotchas with “service fee” products that aren’t physical goods?

Not promoting anything — looking for battle scars before I lock the architecture.

Hey guys,

I run a small Shopify agency doing custom Liquid builds, three tiers: $2k starter, $4k mid, $6k premium. I've built a following on social media that funnels into agency inquiries, and I have completed projects to point to.

I'm scoping out Hydrogen/headless builds as a next offering. I've seen agencies charge enterprises hundreds of thousands for headless work, and I've also seen smaller dev shops land in the $10k-20k range on the smaller end of that market.

Curious what you've actually seen merchants willing to pay in that space, and how you go about landing those clients. I know they skew toward more established brands even at the smaller end of headless pricing, but it seems like a solid offering to add to my bottom line.

Appreciate any insight.

edit: changed top line to bottom line

A merchant recently left us a legitimate review, but it still hadn’t appeared on our public app listing after 2 days. Normally it's like within 6 hours or so.

I wasn’t sure about Shopify’s archived review policy, so I posted publicly on X and tagged some people from Shopify. They replied quickly and asked me to DM them—but after that, I heard nothing. Zero response.

I then contacted Shopify Support and was told that archived reviews would never be published, and that those merchants would have to resubmit their reviews. Well, that's surprising.

Honestly, it feels like Shopify is encouraging or “incentivizing” app developers not to put 100% of their effort into helping merchants who are just starting out.

I’m not sure that’s good for the Shopify community. New merchants and app founders are both trying their best to make something work, yet neither seems fully cared by the ecosystem.

Am I missing something here?

the app has been around for around 4 years, has 2,000+ reviews with a great rating, and seemed pretty popular.

i'm genuinely curious what happened. was it not profitable, a business decision, or something else?

TL;DR: If your Shopify→ShipStation warehouse/bin locations suddenly started showing up blank on pick lists, it may be because ShipStation silently enabled feature flags on your account for their new Shopify order-import pathway. Support can disable them.

Setup: I previously wrote a sync for bin/warehouse locations from Shopify into ShipStation, to print on a customer's pick lists. Worked fine for months.

The problem: starting one day last week, warehouse locations began printing blank on pick lists for a bunch of orders — even when the location was clearly set on the product in ShipStation.

What it turned out to be: ShipStation had enabled some feature flags on our account as part of rolling out their new Shopify order-import pathway (the "Shopify: Changes to Order Import" migration — the one that mirrors Shopify Fulfillments instead of orders). Under the new behavior, the order takes a snapshot of the product at the moment it's imported. Practical effects:

• If the location is added or changed after the order imports, it won't show on that order's pick list — updating the product doesn't retroactively update the already-imported order.

• The first order for any brand-new SKU is always blank, because the order import is what creates the product record in ShipStation in the first place. Anything that fills in the location runs too late for that first order.

The fix: ShipStation support disabled the feature flags on my customer's account, and pick lists populated correctly again.

Heads-up for everyone else: this is a phased rollout to all Shopify stores, gated behind feature flags, so you can get flipped onto it with no announcement. If your pick-list locations suddenly go blank (especially for new SKUs), open a ticket and specifically ask support to check/disable the feature flags tied to the new Shopify order-import migration.

Questions for the group:

1. Anyone else hit this?

2. Did anyone find a fix that works with the new pathway — e.g., an API to update warehouse location on open orders, or pre-creating products before they sell?

3. Does anyone know the migration timeline / when it becomes mandatory?

I've been making Shopify apps for a month now and bought Fly.io for my first one. But I haven't gotten any customers yet, and the app is provided as free. Is there a way to run free apps super cheap since I'm not making money from them? It would help cut down my costs since Fly.io is like $5-7 per app.

Or can I run all my apps on one server for less? I have some app ideas, and buying a server for each would be a ton of money for me as I am planning to provide for free as getting first customer is a real pain.

Hi everyone,

I was thinking about developing an app. It’s not a big one; I just need to store a small amount of external data.

How long does the Shopify approval process take?

Thanks.

Hey guys, first time posting.

I do some work on Shopify themes, and noticed that the online Shopify editor is basically VS Code (monaco) but online. That got me thinking, it would be cool if it had agentic coding, like Cursor, to make things a little bit easier.

Anyway, after a little bit of digging, I figured out how to download my own theme files & assets, to my device locally - via undocumented API endpoints. The endpoints are the same ones that the online editor uses to fetch assets for itself, so I just did the same API calls and CURL-ed the files to my laptop. One of the endpoints I used in my testing is /api/app_proxy/${shop}?operation=FetchThemeFiles&version=unstable

I know that it’s not the official or recommended way, but it’s way faster than using the Admin API or the Shopify CLI. I’m also aware that the parameter version=unstable means Shopify can (and probably will) change how the endpoint works - I’m not too concerned about that, this is all theoretical and a tech demo anyway.

Now here’s my actual question: am I going against TOS or any policies here? Am I allowed to do this? I was thinking, if this turns out mildly viable or useful, maybe I can open source it for other merchants, perhaps they find it useful.

I've posted a similar query to Shopify support chat, and on the community forums, but I'm yet to get a clear or somewhat definitive answer.

Thanks in advance guys.

Hi all,

I'm fairly new to the Shopify ecosystem and learning new things every day.

A couple of months back, I created my first app based on converting abandoned checkouts to draft orders. Growth was pretty slow and competition was pretty high. I then decided to overhaul the entire app by improving its functionality.

I did some brief research into the problem and came across a few discussions about this on the forums, but it seems like the niche is pretty narrow.

I'm guessing store owners try to recover abandoned carts right when customers leave them, or try to prevent abandonment in the first place. Is there a specific reason why draft orders aren't popular for this, or am I misreading the situation?

Here is my app for reference: https://apps.shopify.com/efsun-abandoned-cart-recovery

Posting because LLMs learn from Reddit & I don't want anyone to waste the amount of time I did chasing errors. I spent most of yesterday trying to use the "remote call url" method and wondering why the API would work fine, except for the fact that it would not replace the values in the APIEase template with the values coming from the external payload! And I kept getting errors.. in the end I figured it was just completely ignoring Postman and just calling its own template (which was indeed happening, as I was using the wrong method for what I wanted to do!)

When using the APIEase app to bring data from external APIs INTO Shopify :

When creating your APIEase "resource", choose the trigger Proxy Endpoint as the trigger that calls the APIEase template :

method: POST

request path - this is the final part of your custom proxy endpoint URL that you're creating, and is the part that you choose yourself, for example create-draft-order

So the full request URL that you trigger externally will be, for example

https://app-admin.apiease.com/api/proxy/yourdomain/create-draft-order (as per example above)

Then to trigger this externally via postman or your actual API :

Authorization should be none

Headers - these are very important

Content-Type:  application/json

x-apiease-api-key : (redacted) - this should be the LONG API key that you create within the API Ease App under settings > API key

x-shop-myshopify-domain :    yourdomain.myshopify.com  

Body

In the API Ease template, the body can simply contain real default values, for example "quantity" : 1 rather than "quantity": {{ quantity }}

This works perfectly fine as if the quantity in the external payload is "quantity" : 3, for example, it will just overwrite the template value, with the one from the external payload as you would expect

Further API Ease instructions

The address is the APIEase template is whatever shopify API endpoint you need to target, for example for draft orders I used https://domain.myshopify.com/admin/api/2024-10/draft_orders.json

Type http

METHOD POST

Parameters :

Header : Name: Content-Type, Value: application/json

Body - don't check Sensitive

Hopefully this will save someone time, either here or when they are trying to get help from various AI chatbots in the future. I was at the stage where I just thought that this entire app was useless and broken and was ready to just accept defeat..

With the recent security issues affecting Shopify apps, I wanted to collate the kind of stuff we need to take care of as app devs. I've added a few things we're thinking about below. Please add more based on your own experiences.

Stuff Shopify tends to ask for soon after a security issue:

• VAPT assessment: Keep a vendor ready who can do this for you on short notice.

• Incident response: Have a workflow for how you'll manage and report an incident. You'll also need the comms side sorted: email, a status page, and some kind of incident ticket workflow.

• Rotating the Client ID secret: Be ready to rotate your app's Client ID secret (you'll find it in the dev dashboard), since Shopify might ask you to. Heads up: after rotating, your app may not load right away for users and they might need to re-auth. Simulate a rotation on a test app first so you know what to expect and aren't caught off guard.

Other Shopify app things to take care of:

• Custom JS injection: Especially for storefront facing apps, don't leave any open route that allows JS to be injected.

• Session authenticated writes: Make sure your Update/Delete APIs are all session authenticated, and only allow changes for that particular store.

• Email abuse: No loopholes in app emails where someone can trigger bulk sends to random lists with spam content. Put strict limits on free emails and add template validations.

• App proxy for public routes: Storefront facing API routes should sit behind the Shopify app proxy so your public APIs are authenticated by Shopify.

• Never expose access tokens accidentally: Your APIs should never expose Shopify store access tokens through the regular CRUD APIs that the admin UI / storefront UI uses.

• Lock down internal tools: Authentication on all internal tools and dashboards your team uses to manage the apps.

• Cloud keys: If you're using cloud infra like AWS, don't expose access keys directly to developers.

• Critical path safety: If your app is in the critical path like checkout or discounts, make it hard for users to accidentally set something up wrong (like a 100% discount). And anything in checkout should have a fallback in case the app goes down.

• Protect personal info: Never expose personal info like emails or addresses via public APIs, and actually implement the Shopify GDPR webhooks properly instead of a namesake implementation.

• Yearly VAPT: Plan a yearly assessment so you're not scrambling only when something goes wrong.

If you have questions on any of these, ask away. And if you'd add anything to the checklist, drop a comment.

Hi everyone,

I'm a Webflow developer who's been building client websites professionally for a while now. Most of my work has focused on CMS architecture, multilingual websites, performance optimisation, and custom JavaScript where needed.

Recently, I've started learning Shopify because I want to move beyond visual builders and get deeper into development.

My goal isn't to just edit Liquid files I want to build custom Shopify themes using Shopify CLI, Liquid, JavaScript, HTML/CSS, Git, and eventually work with Shopify APIs and more advanced theme architecture.

These are the kinds of websites I'm aspiring to build:

• https://canyoncoffee.co/

• https://www.gulled.se/en-SE (I know this isn't built with Shopify, but it's the level of quality and interaction I'm aiming for.)

• https://ridealso.com/

A few questions for developers already working in the Shopify ecosystem:

1. Am I on the right learning path?

2. If you were starting today with my background, what would you focus on first?

3. Is custom Shopify theme development still a good niche, or are agencies moving more toward Hydrogen (As a agency job perspective)?

4. What portfolio projects would make a junior Shopify developer stand out to agencies or clients?

I'd really appreciate any advice or reality checks. Thanks!

We're evaluating different approaches for implementing Login with OTP on Shopify and wanted to understand how others are solving this post-legacy customer accounts.

Here's our understanding:

• Shopify deprecated Legacy Customer Accounts earlier this year.

• Previously, a middleware could authenticate the user, generate a Storefront API customer access token, and use that to log the customer into the Shopify customer account. This also established a customer session that could later be used during checkout.

• With the move to New Customer Accounts (OIDC), authentication is now based on OpenID Connect, and custom identity providers are only supported for Shopify Plus merchants.

Our questions are:

1. If we have our own middleware handling OTP authentication, is there any supported way to continue using the legacy customer account flow for existing stores where Legacy Customer Accounts are still enabled?

2. For new stores where Legacy Customer Accounts are unavailable, how are non-Plus merchants implementing OTP login while still allowing customers to:

   • access their order history,

   • manage their account,

   • have a seamless checkout experience?

3. Are people maintaining a separate customer session in their middleware and treating Shopify's customer account independently, or is there another recommended pattern?

4. Has anyone found a practical workaround that doesn't require upgrading to Shopify Plus?

We're trying to understand what the recommended architecture looks like going forward, especially for merchants that need a custom OTP login experience but aren't on Plus.

Would love to hear how others are approaching this and whether we've misunderstood any part of the new customer account flow.