Hi there! We’re hoping to see soon that Shopify is adding API access/endpoints for Purchase Orders - given that this hasn’t been available yet, and Shopify now seems to be planning to discontinue the Stocky app - which does have Purchase Order access? 
Hoping for a response from someone with Shopify here to help add some clarity to merchants who are currently using Stocky and nervous that it’s going away with no similar alternative.
From what I have gone over with Support staff, the only resolution at this point is to go pay for an ERP. I just got us out of a NetSuite ERP and was able to have Stocky do about 90% of the lifting and I am not going back to an external ERP - sunsetting Stocky so they can focus on UCP and Agentic solutions and forgetting how brick and mortar operate is ridiculous IMHO.
This whole sunsetting of stocky was not very well thought out. Hopefully heads will roll. Everything we do in retail starts with the purchase order. The current Shopify purchase order does not do the job. We will have to hand write purchase orders to send to our vendors. The receiving process is archaic. How do you print tags for the products you receive? How do you tie in your invoices to the receiver? Oh no receiver. Totally not properly thought out. It is a shame to throw out the far from perfect Stocky and replace it with a product that is not a workable solution. Heck even small stores cannot use the program. Terrible move Shopify. Shopify maybe one day your employees will be knowledable and successful retailers.
We’re also hoping that Shopify will reconsider the Stocky sunset based on comments in this thread - if they don’t plan to bring the same functionality internally to Shopify Purchase Orders. Certainly agree it doesn’t seem to be the right step forward if that’s not the case.
@Liam-Shopify we’d (and our users) would really appreciate any information/insight/plans around this that you might be able to share?
Shopify please reconsider sunsetting Stocky! We use the forecasting, printing of labels, receiving, scanning etc in the PO program. What you are offering as a replacement is inadequate to run our business.
Has anyone found an app that will substitute instead of just using shopify?
There are alternatives, but it honestly depends on the features you’re using. Some of the features you’ve mentioned, “printing of labels/tags”, “receiving”, “scanning inventory”, “purchase orders”, etc. are all handled with an app like FyreTrail as well and likely better simply because it is 100% Brick and Mortar focused. Check it out and see if something like that will help with the shortcomings of not only Stocky, but Shopify’s PO’s in general.
I’ll be straight up though and also say that FyreTrail is not a Stocky duplicate - it just wasn’t made to be a replacement. FyreTrail’s focus is to help small stores process Purchase Orders and get their products into Shopify easily while also handling a lot of the other needs a small retail store has (budgeting, inventory management and reporting).
This is the response I got from them recently about some of the functionality.
Your Concern |
Status | Notes |
|---|---|---|
| Min/Max replenishment | Not planned for 2026 | Recommend Inventory apps |
| Generate PO based on inventory settings | Not planned for 2026 | Recommend Inventory apps |
| Pre-populate supplier level PO at supplier level | Available now | All recommended apps include supplier management |
| Custom fields/status designations | Not available | Tags can serve as partial workaround |
| Supplier code on POs | Not currently available | Gap for now - but our team are working on this area |
| Bulk CSV import for purchase orders | Not currently available | All recommended PO apps support CSV import: |
I believe most of us are not interested in paying for yet - another app - to be able to complete tasks that should be native to the system we already pay for.
It is beyond comprehension. To me these changes are sending a very clear message to us - and that is - we don’t care what you need to operate…we just got you all locked into contracts and increasing costs….and functionality loss…just pay for yet another app.
AGREE! Huge middle finger to us.
Thank you. Makes total sense - I’m not pushing to use apps, I’m pushing to save time and money based on my own personal experience. My standpoint is; if you’re already paying for a service that does not provide the services you need, why would you not simply ditch that service and replace it with another one that not only better meets your needs, but is also likely overall cheaper because of the time it saves you?
To me, if an app - whatever app - saves you say 6 hours per week at roughly $20/hr in labor (I’m just using an easy number - not sure if that’s high or low) then that’s $120/wk or $480/month in savings for spending $59/month or even $159/month?? Even taking the highest tier still saves money, but if you’re at that level, you’re already saving way more than 6hrs/wk. So to me, it’s very strange someone says that’s not a good deal.
At any rate, thanks for that update… I’m wondering what their “recommended inventory apps” are.
There was nothing fundamentally wrong with Stocky. The Native PO system is fundamentally incomplete. It is not ready to be used mainstream.
That’s a good way to put it it’s not that something broke, it’s that the replacement never fully covered what people were actually using day to day.
Stocky worked because the PO lifecycle stayed connected from purchasing to receiving to inventory and reporting.
Once that connection is missing, even basic workflows start to feel incomplete, especially at scale.
Curious if you’ve tried working with the native PO system yet where does it fall short the most in your workflow?
I think this is where it gets tricky. Even if another tool can create POs, the harder part is keeping everything connected across purchasing, receiving, and reporting.
Once that flow gets split between systems, it tends to add more manual work and reconciliation.
Curious how others are thinking about this going into the sunset are you trying to keep it in one place, or accepting some level of split?
Coming at this from the developer side, so take it with that context: the reason nothing has fully replaced the “print from a confirmed PO” flow is structural, there’s still no Purchase Order API, so apps simply can’t see PO data at all. There’s nothing to build on yet.
On the “keep it in one place vs accept a split” question above: honestly, until a PO endpoint ships, some split is unavoidable, every workaround that exists routes around the PO object rather than through it. Two approaches are out in the wild: apps that hook into the native Transfers page (works if your stock movements live in Transfers), and apps that take a pasted list / CSV of what actually arrived (works wherever your PO lives — supplier spreadsheet, emailed packing list, another system). Neither needs the missing API, which is the point.
And on where native POs fall short most, from what I’ve seen with migrating retailers, it’s the receiving end. Ordered is received — partial deliveries are the norm — and the moment stock lands you need labels printed for what’s actually in the box. That whole step just isn’t in the native flow.
If Shopify does ship a PO API later, these workarounds can presumably plug into it. But with the August cut off, I wouldn’t plan a migration around waiting for it.
We decided not to wait around, and fueled by both our frustration with Stocky’s shortcomings, and our own users asking us for a robust way to handle POs with Shopify; decided to build our own solution.
Check it out at Stockroom - Stockroom ‑ Purchase Orders - Unlimited purchase orders, receiving & sync with QuickBooks | Shopify App Store - we’re making it completely free for everyone. We think Shopify merchants deserve a robust, stable and long term way to handle Purchase Orders in a way that fits their business.
So with Shopify’s DotDev event happening in a couple weeks, there are numerous talks, including one specific:
The Physical Ledger: Inventory gets GraphQL APIs
Real world inventory is messy. We’re bringing it natively into Admin with new GraphQL primitives for purchase orders, stateful counts, and bins. Come see the schemas and build high-scale warehouse integrations.
So it sounds like we will be getting an API for purchase orders (amongst other things too).
Well that answers the thread’s original question in two ways at once. The DotDev sessions description (“GraphQL primitives for purchase orders, stateful counts, and bins”) is the first concrete sign of a PO API. This is surely good news for everyone building around this gap, since every work around discussed above can plug into it, once it ships.
One timing caveat worth stating plainly: a conference session in a couple of weeks means schemas and previews, not a GA API — anyone migrating off Stocky before 31 August still shouldn’t plan around waiting for it.
By the way, congratulations to MyWorks on shipping Stockroom — a free PO + receiving flow with label printing built in is a strong answer for stores that want the whole lifecycle in one place. After this thread’s developments, the remaining gap cases are narrower but real: deliveries whose paperwork never enters a PO system at all (supplier spreadsheets, emailed packing notes), and stores that need more control over the labels themselves — custom sizes, layouts, roll printers. That’s where the label-first tools still earn their keep.
Between an API on the horizon, free PO apps, and the label apps, the post-Stocky picture finally looks less scary than it did in February.