Hi everyone,
I was wondering if this Stocky’s API is still functionnal : API documentation
I appreciate everything is going down on 31st of August but keen to know if we can still use that to extract PO’s until then ?
Thanks a lot
Hi @Pipokx .
Hope you are doing great.
The docs page is still up API structure is still listed.
To be sure it works, test the purchase orders.json endpoint directly.
For certain until Aug 31, check with Shopify support.
Hey @SectionKit team, thanks a lot 
Hello there @Pipokx
The Stocky API is still live until the deprecation date, so you can use this method for extracting POs for now. It’s better to keep your calls for read, rather than build another dependency on it, the way stability probably won’t improve. A good work around is to schedule exports of your purchase orders using Stocky reports, or manual exports using the Shopify admin alongside the API so that you have continuity, your endpoint could fail any time before August 31.
Agreed the above API should be good at least until Aug 31.
If it helps - with Stocky going away, and our own users asking us for a robust way to handle POs and light inventory management / reordering with Shopify; we decided to build our own solution, but for free - and it has a one click migration to pull all your POs in from Stocky, if helpful!
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 (and the re-ordering/receiving processes that come with them) in a way that fits their business, and not at an additional cost.
It seems Shopify will be releasing API’s for native purchase orders in the coming weeks (or months).
Yes — as of right now the Stocky API is still functional, and that doc is the right reference. I’ve used it recently to pull purchase orders, suppliers, stock adjustments and tax categories, and they come out with their relationships intact (which a plain CSV export doesn’t preserve). So to answer directly: yes, you can still use it to extract POs today.
One caution though: “working now” isn’t a guarantee it stays up all the way to Aug 31. As the shutdown gets closer there’s always a risk of rate limits or endpoints going quiet with little notice. So if you’re pulling data via the API, I’d do it sooner rather than at the last minute — get your POs, suppliers and cost data out while it’s stable, rather than betting on it holding until the 30th.
Full disclosure: I’m the developer of UreyukiBox, an inventory app for Shopify, so I’ve been deep in this API lately. Not pitching anything here — happy to share anything specific I ran into with the export if it’s useful.
The API is still up and the auth answers above are right. Two things will quietly give you an incomplete pull though, and both are in the docs rather than being bugs, which is exactly why they are easy to walk past.
First, purchase_orders pages the opposite way round to everything else. Its since_id is documented as returning purchase orders with ID values less than the one you pass. Suppliers, stock adjustments and tax types all say greater than. So the obvious loop, start at since_id=0 and walk upward, returns an empty array from purchase_orders and reads exactly like a store that has no purchase orders in it. If anyone here tried the API, got nothing back and concluded it was switched off, that is worth a second look.
Second, the status filter has eight values rather than the four you would guess: draft, draft-archived, draft-unarchived, confirmed, confirmed-archived, confirmed-unarchived, archived and unarchived. The docs do not state what an unfiltered list contains, so the safe move is to request each status separately and merge on id. Otherwise drafts and archived orders can be missing with no error and nothing anywhere to tell you they existed.
On whether the pull is complete, which is the question above this one: the line item level is where the value is. Every purchase_item carries supplier_cost_price and received_at, the price actually paid on that delivery and the date it landed, and neither is in the CSV export. What is not in the API at any level is free text. No notes field on a supplier, none on a purchase order, no par levels resource, and no stocktakes or transfers resource at all. Those have to come out through the CSV buttons and the Reports dropdown inside the app while it still opens.
I have a script that handles both of the above and writes everything out to JSON and CSV. Plain Python, standard library only, read only, runs on your own machine with your own key so nothing is uploaded anywhere. Glad to put it somewhere public if it saves anyone an afternoon. Disclosure so it is on the record: I build a Shopify app and I take fixed price migration work, so I am not a neutral party here. The two gotchas are free either way and both are checkable at API documentation.
Aislekit’s two gotchas are real — I hit both of them. The backwards pagination on purchase_orders especially: if you test with since_id=0 expecting it to behave like the suppliers endpoint, you get an empty array and assume your store has no PO history. It took me a while to read the docs carefully enough to notice the “less than” vs “greater than” distinction.
On the status filter: I ended up requesting draft, confirmed, and archived separately and merging on ID. Whether draft-archived and confirmed-archived are meaningfully different from archived in practice probably depends on how your store used Stocky, but the safe move is to pull them all.
One thing worth adding to the field-level picture for anyone pulling this data:
What the API gives you that the CSV doesn’t:
purchase_item.supplier_cost_price— the price actually paid on each PO line at time of order, not just the current catalog cost. This is your cost trail.purchase_item.received_at— the real delivery date per line item, not the PO creation date. This is what makes lead-time analysis meaningful.
What’s not in the API at any level:
- Supplier notes (free text). The suppliers endpoint has 18 structured fields — name, email, phone, address — but no notes field. All those per-vendor reminders (“minimum dye lot is a full roll,” “call before ordering Q4”) can’t be automated out.
- Reorder points / par levels. Not documented in any API resource.
- Stocktakes and transfers. CSV export only, as you said.
I built InvoRescue (Chrome extension) specifically around this boundary — it handles the API pull for cost trail and received dates, then runs a structured supplier-by-supplier capture for notes and par levels while you still have Stocky access. One-time purchase, runs in the browser. Link’s on my profile if useful.
19 days left on the API. Worth pulling sooner rather than later given the shutdown timeline.
@irish.chen the API-only versus CSV split you laid out matches what I found, and received_at is the one people underestimate. Order dates come out in the CSV, delivery dates do not, so anything you want to say later about supplier lead times has to come out of the API before the end of the month.
One thing nobody in here has said yet, and it is the part that actually bites: how do you know your pull was complete?
Nothing errors when it is not. Both traps above fail silently, and the way to catch all of them is to stop trusting any single call and start counting. Stocky’s docs do not state what an unfiltered purchase_orders list contains, so you cannot assume it is everything. Request each status separately (draft, draft-archived, draft-unarchived, confirmed, confirmed-archived, confirmed-unarchived, archived, unarchived), merge on id, and compare that count against a plain unfiltered call. If the two disagree, trust the merged set, and look at what the unfiltered call dropped. In testing against the documented behaviour it was drafts and archived orders, which is exactly the history you were pulling for.
Then do the same reconciliation from the other side, which costs nothing and needs no API at all: export the PO list to CSV from inside Stocky and count the rows. Three numbers that agree is the only evidence you get that anything is complete, and after the 31st there is no going back to check.
Worth doing this week rather than in the last few days. If a count comes out wrong you want time to work out why while the API is still answering.
Disclosure so it is on the record: I build a Shopify app in this space and I take fixed price migration work, so I am not a neutral party. The reconciliation above costs nothing and is checkable against Stocky’s own API docs. I also have a read-only Python script that does the status merge and prints the counts, standard library only, runs on your own machine with your own key. Happy to attach it here if anyone wants it.