Does StoreTwin work with Nada (Hide Out of Stock)?
Yes, and the two apps meet in exactly one place, which this page is about. Nada watches stock in the store it is installed in and, when a product sells out, unpublishes it from the Online Store and pushes it to the end of your collections; when stock returns, it publishes the product again. StoreTwin copies products and stock one way between two of your stores and then checks, hour by hour, that the copies still match. Put Nada on the receiving store and the chain is real: an item sells out in your source store, StoreTwin carries the zero across, and Nada hides the item where your customers would have seen it. We ran that chain on a pair of development stores on 7 September 2026 and read every result back from the stores themselves.
We are not affiliated with Digismoothie, the developer of Nada. This page describes what happened when both apps ran on the same pair of stores.
The boundary first
Nada's rules are Nada's. Which products get hidden, after how many days, which collections are sorted and in what order, the redirects it puts on hidden product URLs - StoreTwin neither reads nor copies any of it. We do not sync collections at all: collection membership and sort order in the receiving store are untouched by us, and collections appear in StoreTwin only on the source side, as one of the ways to pick which products to sync. Publication is not ours either: StoreTwin never publishes or unpublishes anything, in either store.
What is ours is the product record - title, description, tags, status, variants, stock and your custom metafields - and that is where the one overlap sits.
What we tested, and what actually happened
Tested on 7 September 2026. Source: a development store with eighteen products. Receiving store: a second development store with Nada installed on its free plan (free for trial and development stores) and set to "hide sold-out products immediately". StoreTwin on the free plan, with syncing switched on for the products picked on the connection page. Each step below was made in one store and read back from both.
| Scenario | What happened | What did not |
|---|---|---|
| Nada installed on the receiving store | Nothing moved: all nineteen products in that store kept their modification times, and not one product webhook reached StoreTwin between the install and the moment we switched hiding on. | No false differences from the install. |
| Auto-hiding switched on, with three products already at zero | Nada hid all three within half a minute, and it hides with two writes: it removes the product from the Online Store, and it adds a nada-hidden tag to the product. | The product status was not touched - the products stayed Active, just unpublished. A fourth product sitting at zero with inventory tracking switched off was left alone. |
| A synced product sells out in the source store | The zero reached the receiving store six seconds after the change, and Nada unpublished the product twelve seconds after that - eighteen seconds from the source edit to a product no longer on the receiving store's storefront. We ran the same step again on a second product: eight seconds to the receiving store, under half a minute to hidden. | Nothing else about the product changed, and StoreTwin did not put it back on the storefront - publication is not a field we write. |
Nada's nada-hidden tag against StoreTwin's repair | StoreTwin removed it, both times, about two seconds after Nada wrote it. Tags are written whole from the source store, so a tag that exists only in the receiving store does not survive the next repair of that product. | It did not un-hide anything, and it did not break Nada: Nada keeps its own record of what it hid, and its dashboard listed the product as hidden with the tag already gone. |
| Stock comes back in the source store | The quantity reached the receiving store nine seconds after the restock, and Nada published the product again thirteen seconds after that - twenty-two seconds from restock to a product back on the storefront, with no action from us and none from the merchant. | The missing nada-hidden tag did not stop it. Republishing did not wait for a merchant to press anything. |
| Products you have not picked for syncing | Their nada-hidden tags stayed exactly where Nada put them, and the check that followed listed each one as a difference - named by product and field, and left alone. | Nothing was written to them. The tag stays, and it is named again in every daily comparison of the two catalogues until you put the same tag in the source store. |
| Hiding a synced product by hand in the receiving store, by setting it to Draft | StoreTwin set it back to Active four seconds later. Status is written from the source store, like the title and the tags. | Draft is not a way to hide a synced product from a receiving store. Nada's way - unpublishing - is, because publication is not synced. |
| Stock changed in the receiving store, as a sale would change it | We took a synced product from 50 to 3 in the receiving store; StoreTwin put 50 back nine seconds later. Stock flows one way, and the source store wins. | So a sale in the receiving store does not make Nada hide anything: the quantity it reacts to is the one we wrote. Sales that must count belong in the source store. |
| Nada's collection sorting switched on | Two things, on two different clocks. Turning it on switched all three collections in the receiving store from "Most relevant" to manual sort order within four seconds - a real change to your store, made by Nada. Then, twenty-four minutes after our write took the product to zero, Nada moved it to the end of both collections it belonged to. | Collection order and membership are not synced, compared or repaired by StoreTwin, in either direction. And the sorting is not on the same clock as the hiding: hiding took seconds, the re-sort took twenty-four minutes, which matches the order of magnitude Nada's own documentation gives. |
Why the pairing holds
Nada acts on two things: the product's publication and its own record of what it hid. StoreTwin writes neither. We write the product's own fields, and the single place the two apps reach for the same thing is the nada-hidden tag - a marker Nada leaves in the store, in a field we keep equal to the source. The tag loses, every time, within seconds; and because Nada does not depend on it, nothing about the hiding or the republishing changed when it went away.
That is worth stating plainly, because the honest version of "these apps work together" is not "nothing collides". Something does collide. It is visible - the same check that repairs the tag names it first, by product and field - and what it costs you is a tag that Nada does not need.
The boundaries, stated plainly
- Publication is never written by StoreTwin, and cannot be: the app asks your store for five permissions - read and write products, read and write inventory, read locations - and publishing is not among them. A product Nada hides stays hidden through every repair, and a product StoreTwin creates in the receiving store is not put on the storefront by us; you publish it once, and Nada takes it from there.
- Collections are not synced: membership, manual order, Nada's sorting rules and the sort order it switches your collections to are all outside StoreTwin.
- Tags are written whole from the source store. Any tag that lives only in the receiving store - Nada's marker, or one of your own - is removed by the next repair of that product, including a repair that was triggered by something else entirely.
- Status is written from the source store too. Draft in the receiving store does not survive; use Nada, or unpublish by hand.
- Stock is copied one way. Whatever the receiving store's own stock says, the next repair makes it the source's number - which is what Nada then reacts to.
- The redirects Nada puts on hidden product URLs are outside our access entirely: we do not read them and cannot touch them.
- Not covered by this run: the storefront as a shopper sees it - both stores are password-protected development stores - and Nada's low-stock e-mail alerts.
If you run both apps
- Put Nada on the receiving store, where the stock we write lands.
- Expect the
nada-hiddentag to disappear from synced products, and do not build theme logic, automatic collections or reports on it in that store. On products you have not picked for syncing, it stays. - Hide by letting Nada unpublish, not by setting products to Draft in the receiving store.
- Keep the selling in the source store, or accept that the receiving store's stock is a copy: it is the source's number that decides what Nada hides.
- After switching Nada on, look at your connection page once: the tags it adds show up as differences, and you should see them repaired or reported, as they were here.
What the app syncs and what it leaves alone is listed in full on what sync apps can and cannot do.
Tested 7 September 2026 with Nada installed on the receiving store of a StoreTwin pair, both stores Shopify development stores, Nada on the plan that is free for development stores. Every line above was read back from the stores after each step. App behaviour changes with releases; if you see something different, tell us at support@storetwin.app and we will re-run the test. The other pairings we have tested: SparkLayer and Arigato Automation. Comparing sync apps themselves: the category compared.
The free plan audits the whole catalogue in your second store and names every difference by product and field - including the ones another app just made - before you switch syncing on.