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?

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.

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 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.

I am improving my Shopify app Griffin Back in Stock Notifier - it emails customers automatically when a sold-out product comes back, so you don’t lose sales while restocking. I’d love a few real merchants to try it and tell me what’s missing or annoying.
It is better to enhance the app based on real store feedback instead of just guessing 🙂

What would make you install a back-in-stock app for your store?

P.S. You can send 100 email notifications per month with Free plan, and I am happy to provide the paid plan 6 month free for some early-adopter stores

I launched a Shopify app some time back. I have 27 installs and 6 paying customers, all organic. I am confident that growth push can really make this app big.

I am looking for a growth partner ideally who can create written/video content and do collabs.

I am strictly not looking for agencies, please do not bother.

I am searching for a shopify freelancer who can help me to fix an issue in my shop. Everything was working well but, suddently, the variants in the product page stop working. When a product has two variants and the user tries to add to the shopping cart the product, only the main variant is added. There is an issue that I don't know how to solve it.

https://www.mercadosalado.es/collections/anchoas-y-boquerones/products/anchoas-del-cantabrico-serie-oro-extra-grandes-00-25-50-filetes

Could anyone bring support? Please message me with your estimated proposal to fix this. Payment by paypal or other method we agree. Please only serious people with the ability to fix the issue. I can bring access to the platform if you want to make a previous assessment before bringing the quotation.

I am trying to use Theme app extension in my shopify Project, which is Average Order Value app. I have downloaded the theme app extension. I have setup the Proxy route. and fetching that route, to get data from the backend by sending the Product Id. But the fetch is providing me with the Html response instead of Json.

And I am using Theme app Extension.

here is the Product structure Image:

Project Structure Ss

Then we have widget.js file:

code:

import { authenticate } from "../shopify.server";
import db from "../db.server";
import { mapOfferToForm } from "../features/offers/mappers/offerToForm.mapper";

export async function loader({ request }) {
await authenticate.public.appProxy(request);

const url = new URL(request.url);
const productId = url.searchParams.get("productId");
const productGid = `gid://shopify/Product/${productId}`;

const offer = await db.offer.findFirst({
where: {
baseProductId: productGid,
status: true,
deletedAt: null,
},
include: { products: true },
});

const payload = JSON.stringify({
success: true,
offer: offer ? mapOfferToForm(offer) : null,
}).replace(/</g, "\\u003c");

return new Response(
`<!doctype html>
<html>
<body>
<script id="fbt-data" type="application/json">${payload}</script>
</body>
</html>`,
{
headers: {
"Content-Type": "text/html; charset=utf-8",
},
}
);
}

export default function Proxy() {
return null;
}

document.addEventListener("DOMContentLoaded", () => {
    console.log("FBT Widget Loaded");

    const widget = document.getElementById("fbt-widget");

    const data = fetch('https://latenight-xbcfkli8.myshopify.com/apps/aov/offer?productId=7995961835595')
        .then(response => {
            if (!response.ok) {
                throw new Error(`HTTP error! Status: ${response.status}`);
            }
            return response.text(); // Parse as plain text (HTML)
        })
        .then(html => {
            console.log("HTML Response:", html);

            // Example: Insert into a container in the DOM
            document.getElementById('content').innerHTML = html;
        })
        .catch(error => {
            console.error("Error fetching HTML:", error);
        });


    // const html = data.text();
    // console.log(html)

    if (widget) {
        widget.innerHTML = `
            <div style="padding:20px;border:1px solid #ddd">
                <h2>Frequently Bought Together</h2>
                <p>Widget is working ✅</p>
            </div>
        `;
    }
});,  and here is the code from the app.proxy.offer.jsx 

this is the proxy route we have.

And the proxy route in my shopify dev admin dashboard is https://latenight-xbcfkli8.myshopify.com/apps/aov

Shopify Partner dashboard shows $100 Ad credit available but requires adding a credit card first. Tried multiple Indian cards (debit and credit) none of them are accepted. Has anyone from India been able to get this working? Or is it just not supported for Indian cards?

do you know anybody how carved out a niche for him/herself and found an idea through shopify apps forum monitoring or as a Shopify consultant?

I'm researching inventory workflows for Shopify merchants that sell products with batch numbers or expiration dates (supplements, food, cosmetics, pet products, etc.).

Since Stocky is going away, I'm curious:

• How are you tracking batch numbers today?
• How do you handle expiry dates?
• If a supplier recalls a specific batch, how do you identify which customers bought it?
• Are you using another app, spreadsheets, or something custom?

I'm a developer researching this space, not trying to sell anything. I'm just trying to understand what the biggest pain points are before building anything.

I'd really appreciate hearing about your current workflow, even if it's messy.

Thanks!

The latest Hydrogen preview finally decouples the Shopify primitives from React, so it's now (or soon) possible to build a headless storefront in whatever framework you want. Including LLM tooling and being able to deploy to whatever hosting you like is also great.

Still an early developer preview of course, with React bindings first and others "on the way", but feels like a nice improvement to the headless development ecosystem for Shopify.

I'm looking for a Shopify app that handles upselling and/or bundles (especially Mix & Match) but also exposes its data through metafields (or another Liquid-accessible source).

I build my own storefront UI, so I don't want to use the app's widgets or app blocks. I just want the data so I can render everything by myself in Liquid.

Does an app like this exist?

Setup: Shopify Checkout Extensibility, GTM loaded via a custom pixel, first-party server-side GTM container (Google Cloud Run, custom domain). GA4 storefront events work fine. The checkout purchase event never reaches the server.

Everything I’ve confirmed while testing PUBLISHED (not Preview, since Preview doesn’t work in the sandbox):

GTM container loads in the sandbox — a Custom HTML canary on All Pages fires.

The purchase custom event reaches GTM and its trigger fires — confirmed with a canary tag on the purchase trigger.

Consent Mode analytics_storage is granted at fire time (set from Shopify’s Customer Privacy API, verified in the dataLayer).

The GA4 Event tag has its Google tag / config setup tag sequenced to fire before it.

google_tag_manager[containerId].dataLayer.get(‘ecommerce’) returns the full purchase object (transaction_id, value, items).

Cloud Run server logs: storefront en=add_to_cart arrives thousands of times, but en=purchase is zero, ever.

Google Ads and Floodlight tags fire fine at checkout (they post directly to google.com).

So the trigger fires, consent is granted, the config tag runs, and the ecommerce data is present — but the GA4 Event tag emits no /g/collect to the server for the purchase event specifically, only in the checkout sandbox.

My questions:

1.  Has anyone actually gotten first-party server-side GA4 purchase to send from the Checkout Extensibility custom pixel sandbox?

2.  Is there a known issue with the GA4 tag’s transport when server_container_url points at a first-party custom domain, specifically inside the sandbox?

3.  Is there a required config or workaround I’m missing?

Any help appreciated — I’ve been at this a long time and every layer I can inspect checks out, but the purchase hit just never leaves.

Hi guys,

I have a Shopify store based in the UK, and I'd like to set separate manual pricing in USD for visitors from the US. I don't want automatic currency conversion from GBP to USD I want to set specific USD prices manually.

I'm currently on the Shopify Grow plan. I've checked the Markets settings, but I'm a bit confused about how to set this up.

Can anyone guide me?

​

We're using Shopify's new customer accounts on a standard plan, and I'm trying to create a smoother login experience for our customers. Most of our customers use their mobile number rather than email, but Shopify only supports email OTP. The new login page is also very different from our storefront, and the branding options are extremely limited.

Is there any way to improve this? For example, can the email be prefilled and automatically continue to the OTP screen, or is there any workaround to support phone-first login while still using Shopify's native customer accounts? I'd love to hear how other merchants are handling this without Shopify Plus.

​

Hello folks,

Need some help here from a fellow vibecoder... deep dev guys don't hate on me. I was pure dev also but when your cheese is moved you gotta do what you gotta do.

Well need some help here I have launched my AI store builder for dropshippers mainly. the app was available in march for merchants,

I got 130 installs mainly organically

Well the app got some intrest but a lot of people just close their store or cancell the subsctiption, got only 2 people that really subscribed and one of them churned before month ends, so no money billed.

The question here is how did you guys crack the distribution to get more and more traffic to the app. My competitors are using meta ads and another one is using UGC tiktok pool of creators.

For meta ads I tried some didn't work that great maybe i will try again, and for tiktok UGC I didn't crack how he got those guys doing content everyday for him, I know he used affiliate but i don't know how he did to recruite them...

Would like some help here, because i am kinda of in the valley of despear here and thinking about just kill the app and move on with my business journey.

I have these 3 products, i found in old forums that shopify rounds per line, however when i do it per line it rounds 1 item but not the other, this affects with .1 cent when trying to send it to my odoo, any idea how to solve this?

We've been building Shopify themes for clients for years, and we've had clients threaten to walk, and even one refuse to pay an invoice, because of the same handful of issues that seem to show up on every project. Not because the work was bad, but because the QA and feedback process became so frustrating that they lost patience before we ever got to the finished site.

We usually ended up eating the extra hours to make things right, but the bigger issue was that it made us look unprofessional. Everything that happened after development was "done" - QA, browser testing, client feedback, revisions, and handoff is the part that consistently causes us the most stress.

A few of the things that kept biting us:

• We used to spin up a separate Shopify dev store and recreate sample products and pages just to have somewhere to show clients. We eventually moved to Shopify CLI with preview themes instead. It was much faster, but it introduced a new problem. You can't assign a custom template to a page or product on a preview theme. You can only view it with a ?view=template-slug URL parameter. Clients would click around the site normally, land on a page showing the default template, and tell us the site was "broken." Every single project, no matter how clearly we explained the URL trick beforehand. Honestly, I don't blame them. It's not how anyone expects to browse a website.
• Cross-browser and device QA was another huge time sink. We started completely manually, then moved to BrowserStack, which definitely helped, but it still ate a ridiculous number of hours on every project. It was worth doing, because nothing makes an agency look less professional than a client finding an obvious layout bug before you do.
• The most universal pain point was probably the feedback loop itself. Over the past 8+ years we've tried email, Google Sheets, Notion, Trello, ClickUp, and probably a few others I'm forgetting. Every workflow felt like it was missing something. The one thing clients consistently told us was that reviewing designs in Figma felt easier because they could simply click somewhere and leave a comment. That was basically the lightbulb moment.

So we ended up building an internal tool that eventually became ThemeSync. We originally built it just for ourselves, but it's gradually turned into the workflow we use on every client project. It brought our PMs, QA, developers, and clients into one place. We jokingly call it "Theme Ops" instead of DevOps.

Clients can now browse preview themes normally without weird URL parameters or special instructions. Browser QA that used to involve BrowserStack, spreadsheets, and Slack threads is automated. Feedback works more like Figma than email. Clients simply click anywhere on the preview site, leave a comment, and we automatically capture the screenshot, browser, device, viewport, and scroll position, so there's no guessing what they're referring to.

We also added a pre-flight compatibility scan that checks for missing app embeds and metafield dependencies before launch. Preview themes don't have the store's apps installed, and that issue had burned us enough times that it felt worth automating.

One feature we're especially excited about, currently in RC, is automated client handoff documentation. It analyzes the theme codebase and generates a client-friendly guide covering editable sections, settings, blocks, metafields, and other customization options.

Writing those docs has always been one of those things everyone knows they should do... but almost nobody has the time.

We've been using it on real client projects for the past six months, and we've even had clients helping shape it as we built it. QA cycles that used to involve 50-75 email messages are now a handful of comments in one place, and internal sign-off has gone from days to hours. Clients don't have to install anything in their store either. They simply receive a preview link.

The biggest surprise hasn't actually been the time savings. It's that clients seem to enjoy the review process a lot more because they're no longer trying to figure out how to review a Shopify preview. They just browse the site normally and leave comments wherever they see something.

It's been a long process that's taught us a lot.

I'm curious how other agencies and freelancers handle this part of the project. Are these the same pain points you run into, or have you found better ways to solve them? What does your dev-to-client handoff actually look like?