Brands and categories are per store — and Fulify now tells you before a sync fails

If you run more than one BigCommerce store, this is the most important release in a while.

The bug: brand and category ids are not shared between stores

BigCommerce gives every store its own ids for brands and categories. "Acme" might be brand 42 on one store and brand 117 on another — or not exist on the second store at all.

Fulify was storing one id per brand and one per category, and sending it to whichever store a product was going to. On a single-store account that works. On a second store it either attaches the product to a completely unrelated brand or category, or the sync is rejected.

Fulify now resolves brand and category ids per store, and the existing links have been corrected across all accounts. If you'd found that a product synced to one store but not another — or that removing a category made the sync succeed — this was why.

Told before you assign, not after you sync

Assigning products to a channel now runs a readiness check first and tells you which ones the channel will refuse and why — the brand isn't on that store, there are no categories, there's no SKU — before you assign a single one.

Assignments the channel genuinely cannot accept are refused, with an override if you're about to create the missing pieces yourself. The same check runs on single-product Add to Channel.

Previously this arrived one failed sync at a time, which on a catalogue-sized assignment means discovering the same fact thousands of times.

Sync failures now say what went wrong

Per-channel sync errors are shown on the product, and the category error in particular now distinguishes the two things it used to conflate: this product has no categories and this product's categories aren't on this store need completely different fixes, and the old message named both at once.

A channel tab offers only that channel's categories

When you're editing a product for a specific channel, the category picker now shows that channel's categories rather than everything in the catalogue — so you can't pick something that will fail.

Replace an API token without rebuilding the channel

BigCommerce tokens expire and get rotated. You can now replace the token in place, keeping the channel, its assignments and its history. Previously the only route was deleting the channel and starting again, losing all of it.

Linnworks

• Rate limiting handled properly — Fulify paces itself against Linnworks' real limit and backs off on a 429 rather than hammering through a run.
• A storefront failure no longer stops stock reaching Linnworks. The two were chained, so a BigCommerce rejection meant the warehouse never heard about the product either.
• Products Linnworks stocks now track inventory automatically — and because not everyone wants the PIM deciding that, inventory ownership is a setting, not an assumption. Linnworks can own stock while something else owns price.

Imports

• The CSV template now documents variants, and the format it declares actually works.
• Channel import is gated per store, not per organisation — a second store could no longer be seeded because the first one had products.