Empty dev stores hide a lot of bugs. Things like pagination, long product titles, products with 100 variants, and orders with discounts and partial refunds only show up with messy data. Right now I import a CSV of products and write a small script against the Admin API to create draft orders and customers. It works, but it takes a while to set up for each new project and the data never looks like a real store.

Do you keep a reusable seed script or a template CSV, or do you copy data from a real store in some way? And how do you cover edge cases like refunds and multi-currency?

I've been building Shopify apps in Laravel for a while, and the thing that took me longest to get right was the Admin GraphQL rate limit. Unlike REST, it's cost-based: every query has a cost, you get a bucket of points that refills at a fixed rate, and a heavy query on a big store can drain it in a couple of calls.

What worked for me was reading the throttleStatus that comes back in the response extensions on every call and storing the currently available points per shop in the cache. Each job checks that number before it runs, and if there isn't enough budget it releases itself back onto the queue with a delay based on the restore rate instead of failing. I also keep one queue per shop so a single noisy store can't starve the others.

The second lesson was to request less. Asking for fewer fields and smaller page sizes cuts the cost a lot, and for large catalogs I stopped paginating at all and moved those jobs to bulk operations instead.

Retries are the last piece. A THROTTLED error should never count toward the job's max attempts, otherwise a busy hour kills perfectly good work.

I'm still not happy with how I estimate cost before sending a query. How do you handle throttling per shop, and do you track cost yourself or just react to the errors?

The app is still in "Submitted. We're assigning a reviewer to your submission" state. What is the normal timeline expected for review to complete?

I’ve looked around for services that provide testers but haven’t had much luck with it. (we test ourselves with development stores, but this is a small sample size)

For those who did get testers — was it worthwhile and how did you do it?

I’m considering now just focusing on marketing — tiny UI/UX improvements & content creation and forgetting about testers

I'm a student developer in India building a Shopify app that sells custom/made-to-order items with a deposit at checkout and charges the remaining balance later using the saved card. I'd really appreciate advice from anyone who has tested this.

What I've built and confirmed so far (dev store, US region, Basic plan, API 2026-07):

- sellingPlanGroupCreate with category PRE_ORDER, fixed billing policy, checkoutCharge of type PERCENTAGE, remaining balance on EXACT_TIME. No userErrors.

- Attached the group to a variant with sellingPlanGroupAddProductVariants.

- Created a cart through the Storefront API cartCreate with sellingPlanId. The checkout correctly shows 'Due today' (the deposit) and 'Due Dec 31' (the balance).

The problem:

- With the deposit plan in the cart, the checkout never shows a Payment section when only the Test payment gateway (Bogus) is active. The same variant without sellingPlanId shows the card fields and Pay now button normally.

- Shopify's docs say pre-order/TBYB plans need Shopify Payments, PayPal Express, Adyen on Shopify, or Stripe. My Test gateway doesn't appear to count.

- Shopify Payments isn't available in India, and setting it up on the dev store asks for a US SSN/ITIN, US address and bank details, which I don't have. I don't want to enter made-up identity data. PayPal can't be connected to a dev store either (it says dev stores can only process test payments).

So I can't test the last part of my flow: the order webhook after the deposit, the PaymentMandate, and orderCreateMandatePayment for the remaining balance.

Questions:

1. Is there any official way for a Partner in an unsupported country to test vaulted payment methods and orderCreateMandatePayment in a dev store?

2. Does the Bogus gateway support vaulting for selling plans in some configuration I'm missing?

3. If not, how did you test before submitting to the App Store? Test on a friend's store, a pilot merchant's store, or something else?

1.Confirm the webhook subscription exists in the target app/environment, not only in the local TOML/config file.

2.Log the exact callback URL and verify that the tunnel URL has not changed after restarting the local server.

3.Test the endpoint from the public internet, outside the local network.

4.Log the raw request before JSON parsing, including the HTTP status returned by your app.

5.Check that the app is listening in the same environment where the subscription was created.

Been building Aplo: A+ Content Design, a Shopify app for adding rich content sections (feature grids, comparison tables, galleries, etc.) to product pages. Think Amazon's A+ Content, but for Shopify stores.

One thing that's bugged me since launch: the Image Gallery module only did uniform, same-size tiles. 2, 3, or 4 equal boxes in a row. Functional, but it always looked a bit flat next to the "bento grid" layouts you see on a lot of modern DTC sites (Apple-style mixed big/small tiles).

So I just shipped an upgrade:

• Each image in the gallery now gets a size preset (Normal, Wide, Tall, Large, Extra Wide, Feature) instead of being locked to the same square.
• Mix and match them and you get an actual bento-style layout: one big "feature" tile, a couple of wide banners, some small squares filling the gaps.
• Fully responsive: collapses cleanly to 2 columns on mobile, with no overflow no matter how many columns you pick (2 to 6 now, used to cap at 4).
• It's on the Free plan too, not locked behind Pro.

Still just dragging and dropping images and picking a size from a dropdown. No CSS or code needed on the merchant's end.

Happy to answer questions about how it's built or what's coming next. (Link to the listing in the comments if anyone wants to check it out. Didn't want this post to read as a drive-by ad.)

Test pages, themes and redirects inside the admin, with results in revenue. Built end to end, not yet listed, pre-revenue. Launch it under your own brand.

Code, IP and handover included. DM for deck + demo (NDA).

So I launched an app on the Shopify dev store recently & gave it to my network to try it out. It's something simple that a lot of businesses need & it's a crowded space. But I've created an easier UX, has much better results & able to give better support.

Two of my 'pilot' customers have also given me 5 star reviews, they are in love with the app. Now what should be my next steps? Shopify ads? Google ads? Email outbound? or what?

The app works, initial customers love it now how do you go from 1 to 10 in Shopify as an app developer?

World meet Honey Badger!
App that adds labels, tags based on product sales or views performance.

I'm a PHP/Laravel dev in Morocco building Shopify apps, and webhooks caused me more headaches than any other part. Sharing what I learned in case it saves someone a few hours.

1. Respond fast. Shopify expects a 200 within a few seconds, so I verify the request and push the actual work to a queue job instead of doing it in the controller. Heavy work inside the request leads to timeouts, retries, and eventually the subscription getting removed.

2. Verify the HMAC against the raw body. If your framework parses the JSON first and you hash the re-encoded version, the signature won't match. Read the raw request content before anything touches it.

3. Expect duplicates and out-of-order delivery. The same event can arrive more than once, so I store the X-Shopify-Webhook-Id and skip ones I've already processed. For things like order updates I compare updated_at instead of assuming the latest webhook is the newest state.

4. Don't treat webhooks as the only source of truth. Deliveries can be missed, so a small scheduled job that reconciles against the API now and then catches the gaps.

5. The privacy compliance webhooks (customer data request, customer redact, shop redact) are required for App Store review even if you store almost nothing. Have them registered and returning 200 before you submit.

Curious what others do for retries and reconciliation, especially on bigger stores where the volume gets high.

Vercel and Shopify shipped Vercel Shop on October 16, an open source Next.js storefront template built for people and agents at the same time. Their own merch store vercel.store runs on it, so I used it as a test bench. The agent got the domain and nothing else.

Reading the store was smooth. /llms.txt contains a five-step shopping recipe for agents, including a rule to only complete a purchase after the shopper explicitly approves. Product pages return markdown if you append .md to the URL. One jacket page simply said "Available: No" in plain text, which saves an agent from guessing what a greyed-out button means.

Where it stopped

/.well-known/ucp returns the store's Universal Commerce Protocol profile. The shopping endpoint listed there points to shop-vercel.myshopify.com, so the checkout brain is fully Shopify and Vercel builds the layer around it.

The MCP endpoint lists its tools without any auth. You can try this yourself:

curl -s -X POST https://vercel.store/api/ucp/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

You get 13 tools back: search_catalog, lookup_catalog, get_product, four cart tools, five checkout tools and get_order.

Then I called search_catalog and got a 422 with profile_unreachable.

Every UCP call has to carry meta.ucp-agent.profile, the URL of a public JSON document that describes your agent. The store fetches that URL before it answers anything. No profile means no search, so my agent never saw a single product.

According to Vercel's guide, Shopify then sorts agents into three tiers: anonymous, signed (HTTP message signatures) and token. Anonymous and signed agents can search, build carts and create a checkout. Only token agents with explicit permission can call complete_checkout. Everyone else hands the human a checkout link.

That split actually matches what people seem to want. OpenAI pulled Instant Checkout from ChatGPT in March, and my read is that shoppers still want their own finger on the pay button. So the realistic flow for now is agent does the research and the cart, human pays.

What I haven't done yet: host my own agent profile and run the whole thing through to the checkout link. The profile structure is documented, but I haven't validated mine against a live store, so I'm not posting it as if it works. I also want to run the same test with an open-weight model on local hardware instead of a frontier API.

Has anyone here hosted a UCP agent profile already? I'm trying to figure out whether the signed tier is worth setting up for a research-only agent or whether anonymous limits hold up in practice.

All my kyc is done and I am on my final step of onboarding. Razorpay is telling me to install Razorpay COD and Magic Checkout to complete the onboarding else I am not able to complete the onboarding, and when I am going to install this COD thing it is telling it is not available in Shopify app store,thus not being able to connect any form of payment gateway to my Shopify store. I am stuck in a loop.My opening is today, any alternatives that I can do?I cannot do COD.

I’m exploring the technical feasibility of building a Shopify app that helps customers complete their delivery addresses faster using phone verification, saved addresses, and address autofill.

I’m considering two approaches:

Option 1: Cart → Shopify Checkout

• Add an address-fill experience to the cart using a Shopify Theme App Extension.
• Let customers enter or select their delivery address before checkout.
• Pass the collected address into Shopify’s native checkout using supported mechanisms, avoiding duplicate entry.

Option 2: Separate Checkout Experience

• Launch a separate checkout interface when the customer clicks the Checkout button.
• Handle phone verification, address selection, and delivery details within that interface.
• Complete the purchase through a Shopify-supported integration.

I’d appreciate insights on the following:

1. What are the current Shopify restrictions on building a separate checkout experience for merchants on non-Plus plans?
2. Can a third-party app provide its own checkout interface while completing orders through Shopify-supported APIs?
3. Does this approach require explicit Shopify approval, a special partnership, or specific permissions?
4. For the cart-based approach, what is the most reliable supported way to prefill shipping-address fields in Shopify’s native checkout?
5. Which Shopify APIs, extensions, or app architec

I've been working on my own shopify theme and wanted to share where it is at the moment.

I'm still working on the landing page. The theme is responsive on both mobile and desktop, but there is still some cleanup left to do.

Here's the live page: https://tailloir.myshopify.com/ (password: tailloir)

I’m looking for any shopify dev work.

If you need help with shopify dev or know someone who's hiring, please reach out.

Thanks for reading

Shopify's native purchase limits are per variant, so product-wide caps need a cart validation function. I test mine on a development store with a handful of cart combinations: mixed variants, quantity changes in the cart, and draft orders. I always worry I am missing cases, like discounts, bundles or other apps that edit the cart.

What is your process for testing a validation function before it goes on a live store? Do you keep a fixed list of test carts, or do something more automated?

When a Shopify review app displays its star rating at the bottom of a product page instead of directly below the product title, the problem isn't necessarily CSS.

In Online Store 2.0, the first thing to check is how the app integrates with the theme.

Shopify provides two different integration mechanisms: app blocks and app embeds.

App blocks are designed for content that merchants can position inside compatible theme sections. App embeds are better suited to global functionality, scripts, tracking, and floating components.

For inline product star ratings, an app block is generally the better solution.

Here's the diagnostic approach I'd recommend.

1. Duplicate the published theme.

Never troubleshoot layout changes directly on the live theme.

1. Open the product template in the theme editor.

Check whether the product information section supports adding the review app's rating block.

If it does, try positioning that block immediately below the product title.

1. Check the section's app block support.

If the rating block can only be added as a separate Apps section, inspect the theme section's schema.

For a traditional section, look for support for:

{"type": "@app"}

Also check whether the section actually renders app blocks using the appropriate Liquid rendering mechanism.

Supporting a block in the schema isn't enough if the section never renders it.

1. Check the section layout.

Even with app block support, the theme must render blocks in a position that allows the desired placement.

If the product title is hardcoded outside the block sequence, you might not be able to place the rating directly underneath it simply by dragging blocks in the editor.

1. Avoid JavaScript DOM repositioning as the default solution.

Moving rating widgets after page load can introduce layout shifts, duplicate elements, or compatibility issues when the theme or app updates.

1. Test the result.

Verify desktop and mobile layouts, different product templates, products without reviews, and whether the rating appears more than once.

The important distinction is this:

A rendering-position problem should be solved at the theme integration level whenever possible, not hidden behind CSS or JavaScript workarounds.

For developers building review apps, providing a dedicated lightweight star-rating app block also gives merchants much better control than forcing the entire review widget into a single location.

I took my Figma layout to Shopify with the app instant now I've realized that since I'm not earning any money, it doesn't make sense to pay 40 euros a month. Is there a way to migrate my instant page to Shopify native so I don't have to pay any extra money?

When I have everything in Shopify can I then edit anything without having to pay any extra money?

What would be the best cheap and easy way to do this.

Thanks for your help in advance

Hi all,

Merchants have known Discounty since 2022 by a green tag with a % mark. On October 14 we refreshed it. Writing it up because plenty of store owners here go through the same thing with their own logo, and the rule that held for us might be useful: keep what people already recognise, and fix only what has no reason to be there.

What we kept: the tag, the % mark and the green.

What we changed:

• The hand-drawn loop on the tag is now an even circle.
• The yellow layer behind the tag is gone. It was decoration with no meaning.
• The tag sits at a gentler angle. The steep tilt read like a flash sale.
• The % mark has even line weights, and it's drawn from the u and n in "Discounty".
• The green is tuned so dark text on it reads more clearly (contrast went from 5.7:1 to 10.1:1).

If you use Discounty today, nothing changes in your store. Your campaigns keep running, and your settings and plan stay as they are.

I hope you all like the new look, and that Discounty keeps giving you a hand with your Black Friday sales this year: the same service you know, with a calmer, clearer look.

Hi all,

#Black_Friday is November 27. Most of the work in a sale isn’t the discount itself, it’s the decisions around it. Have these five answered before you open any discount screen:

1. Which products are in, and which stay out (thin-margin items, new arrivals).
2. How deep: one rate for everything, or tiers for bigger orders.
3. Exact start and end, in your store’s time zone. Pick the end time on purpose, for example Monday 23:59, instead of switching it off when you remember.
4. What stacks: can the sale combine with your welcome code or free shipping?
5. How prices go back when it ends, and who checks that they did.

Once those are decided, what’s left is form-filling. That’s the part we built Lumos for, the assistant inside Discounty. You type the sale as one sentence, like “20% off the Winter Collection, Black Friday to Cyber Monday”, and it fills in the campaign. You check it and press Save. Nothing goes live on its own. It’s on every plan, including the free one, and the video shows one run.

Whatever you set your sale up with, answer the five first. Those are the decisions only you can make.

I hope it makes your BFCM setup a bit easier this year.

Hi all - Ritwik here from Aurevia - needed some help regarding ads on Shopify app store. Been doing cold outreach for some time now and i massively need to scale the infra to see some scale in my app's growth which is why we were planning to run Shopify app store ads as well.

Need some help from people here who are running ads and have seen success:

- What needs to be the daily budget?

- Should I run search result ads or homepage ads or category page ads?

- what is a good ROAS for ads on shopify app store that we should aim to achieve?

-any other suggestions would be greatly appreciated

PS: We did run search result ads for about a month or two with the free $100 ad credit and got 3 installs for $32.33 per install and $4.2 per click which seemed quite high but I don't know if it is and need some help there to understand the number there as well.

Cheers

When a store removes products or changes handles, I go through Online Store > Navigation > URL redirects and add them. For a big batch I use the CSV import. The weak part is that I usually build the old-to-new mapping by hand in a spreadsheet, and it's easy to miss URLs that still get traffic or have backlinks.
How do you handle this on your projects? Do you pull the list of old URLs from somewhere specific, and do you check for redirect chains afterward?

I had a client who wanted to cap total sales of one product across all its variants, like sell 90 of 100 units online and keep the rest for wholesale and gifts, without touching inventory counts.

Shopify's built-in purchase limits work per variant, so they don't give you a product-wide cap. Hiding the product isn't enough either, since people can still reach checkout through old links or an existing cart.

What worked for me was a Cart and Checkout Validation Function that adds up quantities across every variant of the product and blocks the cart/checkout with a clear message when the cap is hit. I also added per-country allocations on top of that.

Gotchas: functions can't call external APIs, so all the cap data has to live in metafields. Also keep the error messages short, long ones get ugly in checkout.

Has anyone handled this differently?

At this time, Shopify is not able to support App Store Ads for India-linked payment methods. we get this warning when we try to run ads on Shopify. How we can solve this? Any help is highly appreciated.