What actually survives a Stocky export — I went through the API docs field by field

Retail & Point of Sale
,
1

There are good threads comparing replacement apps, but I kept hitting the same blind spot: nobody had laid out exactly which data makes it out of Stocky intact, and which is gone no matter what you switch to. I needed to answer this for my own store before choosing a replacement, so I went through the Stocky API documentation directly and cross-checked against my own account. Sharing what I found in case it’s useful.

What the CSV export gives you reliably

  • Purchase order headers and line items
  • Stocktake results
  • Current cost per product at the time of export

These come out cleanly. Any replacement tool can ingest them.

What has no export path at all

Supplier notes. I pulled up the /suppliers endpoint in the Stocky API. It returns structured fields — name, email, phone, address — and nothing else. There is no free-text field. Shopify’s own migration page confirms this outright: “Suppliers can’t be exported from Stocky.” Whatever you’ve accumulated in those notes fields — MOQs, discount tiers, seasonal caveats, which warehouse to avoid — it doesn’t come out automatically. Manual copy is the only route, and you need to do it before Aug 31.

Par levels / reorder point settings. Also absent from both the CSV and the documented API resources. Same situation — manual capture only.

What’s in the API but not in the standard CSV

This is the part I didn’t expect.

First, supplier records. The /suppliers endpoint does return contact and address information, so you can pull a supplier list programmatically — but there’s no bulk CSV export of supplier objects from the Stocky UI itself. If you rely on the standard export flow, supplier details outside of what’s embedded in PO line items won’t be there.

Second, and more significant: each purchase_item in the API has two fields that the standard CSV doesn’t surface cleanly:

  • supplier_cost_price — the cost you paid that supplier on that specific delivery, not just the current product cost. If your supplier costs have shifted over multiple orders, this is where the history lives.
  • received_at — the actual date stock arrived, as opposed to the PO creation date. This is what you need to calculate real lead times per supplier. The CSV only gives you the order date.

Pulling full PO history via the API rather than the standard CSV export gives you the cost trail and actual received dates. The CSV compresses this down to a point-in-time snapshot.

The practical split

Two things have a hard deadline because there is no automated path: supplier notes and par levels. Manual capture now, while Stocky is still accessible.

Two things are recoverable from the API if you pull it before shutdown: full cost history per delivery, and actual received dates.

The replacement app decision is reversible. These aren’t.

Has anyone else verified this against their own export? Curious whether the received_at field made it through into any of the third-party migration flows — I haven’t seen it mentioned anywhere.

(I ended up building a small Chrome extension, InvoRescue, to handle the API extraction and walk through the manual capture for the fields that can’t be automated. Full disclosure: I built it. Happy to answer questions about what it does and doesn’t cover — link’s on my profile.)

2

Hey @irish.chen ,

Thanks for taking the time to document your findings this is a very useful breakdown for merchants planning their migration away from Stocky.

The distinction you’ve made between what can be recovered later and what has no automated export path is particularly valuable. If supplier notes and par levels truly have no supported export then manually backing them up before Stocky’s retirement is definitely something merchants should prioritize.

Your point about the API exposing fields like supplier_cost_price and received_at is also interesting. Those fields provide historical purchasing and lead time information that can be important for reporting and supplier management so relying solely on the standard CSV export could leave merchants with an incomplete data set.

Hopefully others who have completed migrations can confirm whether any third party migration tools preserve those API only fields. That would help merchants decide whether they need to perform an API export before Stocky is retired.

Thank You !

3

@Steve_TopNewYork Thanks for the kind words, and for pulling out those two threads clearly — that’s essentially the crux of it.

On your question about third-party migration tools: from what I’ve seen so far, the standard Stocky CSV export is still the basis for most importer flows, which means supplier_cost_price per delivery and received_at per item tend to get left behind — those fields only appear when you query the API directly at the purchase item level, not in the export files merchants typically hand off to a new tool.

That said, I haven’t tested every option — if anyone has, would love to hear. The reason I ended up building InvoRescue was specifically because I couldn’t find a tool that pulled this layer, but I’d be happy to be proven wrong by a simpler solution.

4

Thanks for the clarification that aligns with what I’d expect if most migration tools are built around the standard CSV export.

It also reinforces an important takeaway for merchants: before migrating, it’s worth verifying exactly which data is being carried over instead of assuming every Stocky field is included. Historical purchasing data can be difficult or impossible to reconstruct later if it isn’t exported beforehand.

Hopefully anyone evaluating migration tools will ask specifically about API only fields rather than just CSV compatibility. That could save a lot of surprises after the migration is complete.

5

@Steve_TopNewYork Exactly right — and to make that concrete, the two questions worth asking any migration tool are:

  1. Does your import pull directly from the Stocky API, or is it based on the CSV export files?
  2. Do you preserve supplier_cost_price and received_at at the purchase item level, or just the current cost and order date?

Most tools I’ve evaluated don’t have clear answers to those yet, which is part of what pushed me to build InvoRescue as a pre-migration step rather than a replacement app — specifically to handle the API extraction before the window closes. But any tool that can answer yes to both questions above would cover the same ground.

6

Thanks for outlining those questions so clearly they’re a practical checklist for anyone planning a Stocky migration.

I think many merchants naturally assume that if a migration tool says it’s “Stocky compatible,” it preserves everything. Your two questions help separate basic CSV imports from tools that actually retain the historical purchasing data stored in the API.

Hopefully vendors will become more transparent about exactly what they migrate. Knowing the answers before starting a migration is far better than discovering missing data after Stocky has been retired.

If you found my reply helpful feel free to mark it as the solution so it can help other merchants facing the same question.

7

@Steve_TopNewYork Thanks for engaging with this so thoroughly — the back-and-forth has made the thread much more useful than the original post alone.

Marking your reply as solution. Hopefully the two-question checklist helps merchants get a straight answer from whatever tool they’re evaluating before Aug 31.

8

Thanks @irish.chen , I really appreciate that! I’m glad the discussion helped bring more clarity to an issue that could easily be overlooked during a migration.

I also hope the two question checklist encourages merchants to dig a little deeper before choosing a migration tool. A few questions upfront can save a lot of time and prevent missing important historical data later on.

Thanks again for sharing your research and taking the time to document it so thoroughly. I’m sure it’ll help many merchants preparing for the transition before the deadline.

Thank you!

9

(post deleted by author)

10

Coming back to your open question, because the answer changed this week. You asked whether received_at made it into any third-party migration flow. Ours reads it now. Not from the CSV, from the Stocky API itself, the same v2 endpoints you went through, and it comes back at purchase item level per delivery along with supplier_cost_price.

We verified against a live store rather than trusting the docs, and two findings are worth passing on to anyone else pulling this data before the shutdown. Partial receipts split the line into two rows exactly as you described, and the backordered half comes back with status “not delivered”. Careful there. If your parser matches on the word “delivered” it counts those units as received, which is precisely the kind of silent corruption everyone in this thread is trying to escape. Ours did it in testing. Fixed, but check yours.

Second, item-level dates are slash-formatted while order-level dates are ISO. Pick a date where day and month differ before trusting your parser. August 8th taught us nothing.

Your findings on supplier notes and par levels stand. No API path. Manual capture now or never. The CSV outlives the API by about ninety days, so the API-only fields are the only ones on the real clock.

Disclosure: I build Binly, and this went live in the app this week.

11

HI @irish.chen

This is probably one of the more important parts of the Stocky sunset that merchants are overlooking. The key distinction is that a replacement app can migrate what Shopify exposes, but it can’t recreate data that has no export/API path.

I’d definitely prioritize capturing anything that is only available inside Stodky before the shutdown rather than assuming the replacement app will handle it later.

The supplier_cost_price and received_at fields are particularly interesting if they are present in the API response for your account, because historical supplier cost and actual receiving dates are much more valuable than simply having the current product cost.

One thing I’d recommend to anyone following this: export/save the raw Stocky data before choosing the replacement, even if you don’t know yet how you’ll use it. Once Stocky is gone, reconstructing historical purchasing information from Shopify alone may not be possible.

And yes, it would be useful to hear from anyone who has actually run an API extraction and compared it with a normal Stocky CSV export. That would make the migration picture much clearer.

12

Can at least confirm one piece with a primary source: Shopify’s own migration doc states flatly that “Suppliers can’t be exported from Stocky” — so notes are confirmed gone regardless of which export path you use, that’s not in question.

The cost_price/received_at-per-line question is one I haven’t nailed down with a real side-by-side yet — I’ve confirmed those fields exist in the API response, but I don’t have a clean field-by-field diff against the standard PO CSV to say definitively what the CSV drops or overwrites. Rather than guess, I’m going to run that comparison properly and post the actual diff here once I have it.

13

Ran that side-by-side yesterday on a live account, so this one now has an answer.

received_at populates on delivered rows, a part-received line comes back as two rows with the backordered half marked “not delivered”, and our importer folds them back into one line while keeping each delivery’s own date. So lead-time history makes the trip whole.

Suppliers come across too. Name, contacts, address, straight from the API.

One heads-up if you’re pulling the data with your own script: the API has a quirk that can hand back an empty result while looking perfectly healthy. Our importer handles it.

Disclosure: I build Binly.

14

Shopify’s migration guide says suppliers can’t be exported and old POs can’t be imported. But Stocky has a read-only API that still works until the 31st, and it gets everything out.

Get your key: Stocky → Preferences → API Access. If that section isn’t there, email Shopify Support and ask them to “activate Stocky API access” — takes a day or two, so do it now.

Test it works:

bash

curl -H "Store-Name: yourstore.myshopify.com" \
     -H "Authorization: API KEY=your_key" \
     "https://stocky.shopifyapps.com/api/v2/suppliers.json"

The API KEY= prefix isn’t a typo. Five endpoints available: suppliers, purchase_orders, stock_adjustments, stock_adjustment_items, tax_types. Add ?page=1&limit=250 and walk the pages.

Stocktakes and forecast settings aren’t in the API — export those by hand.

One thing worth grabbing: the received date on each PO. That’s your real supplier lead time, and it’s the field people don’t miss until they try to plan a reorder without it.

If you’d rather not do it by hand, I wrote a script that pulls all five endpoints into CSVs, plus one combined file with every PO line item joined to supplier, cost, and dates. Python, nothing to install, read-only, runs on your machine, no signup:

Full disclosure: I’m a developer looking at building a replacement for the reorder/receiving side of Stocky, and wrote this while researching. Script’s free either way. If you used Stocky daily and would give me 15 minutes on how, I’d really appreciate it. Reach me at stocky@tappacific.com

Happy to help if anyone gets stuck.

15

@tappacific Good contribution — the API summary and the API KEY= prefix note are both worth having in writing. For anyone on the technical side, that script looks like a clean way to cover the same five endpoints before the 31st.

Two things worth flagging for anyone comparing approaches:

The script handles what I’d call the recoverable layer: supplier contacts, PO headers and lines, supplier_cost_price per delivery, received_at. All of that is in the API and extractable before shutdown. That’s the good news.

What neither the script nor InvoRescue can do automatically — because it has no API path — is supplier notes and par levels. Shopify’s own migration doc says outright: “Suppliers can’t be exported from Stocky.” Those fields don’t exist in any endpoint. The only route is opening supplier and PO detail pages by hand and copying them out. How painful that is depends entirely on how many suppliers you’re carrying.

Practical split as I see it: if you’re comfortable with Python and a terminal, tappacific’s script covers the API layer for free. If you’d rather not touch a command line, or you want the manual-capture workflow for notes and par levels walked through step by step, that’s what InvoRescue was built for. Link’s on my profile.

Either way — 20 days left. The API layer is the time-sensitive one.