Draw the inventory states your store passes through, then check whether the data model has a field for each. What has no field ends up in someone's head.
Key takeaways
- Two completely different complaints sound identical: "the site limits us" can mean design, or it can mean the process cannot be represented.
- Wix documents inventory tracking at the variant-and-location level, where each inventory item is identified by a variantId and locationId combination.
- Per the documentation, the availabilityStatus field is read-only and calculated automatically from the tracking method and preorder settings.
- The decrementInventory call is limited to 300 items per call and accepts a preorderRequest flag that allows negative inventory for preorder items.
- No dedicated state for a damaged item, an item under inspection, or safety stock was located in the inventory documentation reviewed. That is a statement about the documentation, not about the capability.
The choice between Wix and custom development is decided by how many states your stock passes through, not by how the site looks. Draw the states, then check whether the platform's data model has a field for each one. A state with no field ends up stored in an employee's head.
Two complaints that sound the same
The first complaint: "we want the page to look different and we cannot." That is a template complaint. It is answered with design, a different template or front-end code, and it is almost never a reason to build a system.
The second complaint: "we have an item that went out for repair, the customer already paid, it was never delivered, and there is nowhere to record that." That is a process complaint. It has nothing to do with design and it does not disappear when you change template.
The problem is that both are voiced with the same words: "the platform limits us." The only way to separate them is to write down the states and look for a field for each.
How many states does your stock actually pass through?
This is the state list that recurs in Israeli stores holding physical stock. Mark the ones that exist in yours:
- Available to sell in the warehouse.
- Held for a customer who has not paid yet.
- Paid and not yet collected or shipped.
- Out for delivery and still your responsibility.
- On order from a supplier and not yet arrived.
- Arrived damaged and awaiting a decision.
- Out for repair or at a lab, expected back.
- With the customer on loan or approval, still yours.
- A serial-numbered item, where each unit is its own record.
- Safety stock that is never sold even when it is present.
A business with only the first four will manage on almost any platform. A business marking seven or more has reached the limit of a data model, and that limit does not move with a plugin. See the worked example in serial inventory flow in an optical store.
What Wix's inventory model documents
| Capability | What is documented | Note from the documentation |
|---|---|---|
| Per-location tracking | Documented | An inventory item is identified by a variantId and locationId combination, and each variant can hold a separate quantity per location |
| Two tracking methods | Documented | Quantity tracking, or in-stock tracking without counts, for made-to-order or digital products |
| Availability status | Documented as read-only | availabilityStatus is calculated automatically and updates when inventory changes |
| Preorder | Documented | Configured per inventory item, meaning per variant-and-location combination |
| Bulk decrement in one call | Documented with a limit | decrementData is capped at 300 items, and each entry needs a decrementBy of at least 1 |
| Negative inventory | Documented conditionally | The preorderRequest flag allows negative inventory when the item is available for preorder |
| Creating a product with inventory | Documented as a separate call | Create Product does not create inventory items; Create Product With Inventory exists for that |
| The inventory field on a product | Documented as limited | The product's inventory field is read-only and reflects the default location only |
| Managing locations | Documented as read-only | The stores locations interface is read-only; creating and updating happens through the general locations interface with "INVENTORY" in locationTypes |
| Damaged, inspection, safety stock | Not located in the inventory documentation reviewed | This is not a claim the capability is missing; no dedicated state for it was found |
The last two rows are the ones that decide projects, not the first ones.
What has no field lives in someone's head
- An item out for repair with no state will show as available to sell, or vanish from the count. Both outcomes are wrong.
- Safety stock with no field is managed by someone "knowing" not to go below three units.
- A serial number with no record of its own becomes a text field in the order notes, and nobody can search it.
- Every missing state produces a parallel spreadsheet, and every parallel spreadsheet produces a contradiction between two numbers.
- Once there is a contradiction, somebody stops trusting the system, and that is the point of no return for the project.
Is the template the constraint, or the process?
There is a short test that separates the two, and it runs in an hour:
- The template question. If we were handed exactly the design we want, would the process work? If yes, this is a design problem and the comparison ends here. The general template-versus-custom comparison lives in a custom website versus Wix.
- The process question. If we were handed an outright ugly site that had a field for every state on the list, would we cope? If yes, the constraint is the data model and not the template.
The common real answer is that both problems exist, but only one of them costs real money. Fix the one producing spreadsheets first.
What custom development buys here, and what it does not
It buys control over the states: you define which states exist, which transition between any two is legal, and what counts as available to sell. It also buys the ability to record a serial number as a record with a history of its own.
It does not buy a finished shop. Design, checkout, content management and payments are work the platform already did, and rewriting them just to gain one inventory state is a poor decision. The shape that works in most cases keeps the existing shop as the front, and moves state management into a separate layer synced to it. See automating inventory management.
Cost shape, without numbers
- What scales with the number of states. Each additional state adds transitions, tests and screens. It is the one factor that genuinely multiplies the work.
- What scales with the number of locations. Multi-location management multiplies inventory records and reconciliation checks.
- What scales with catalogue size. A limit such as 300 items per call determines how many calls a full catalogue update needs.
- What scales with front-end customisation. Design customisations are cheap at first and expensive at every platform upgrade.
- What stays flat. One document defining the states and the legal transitions between them. That asset is what lets you change supplier without starting over.
Sources
Frequently asked questions
What does it mean that availabilityStatus is read-only?
That per the documentation the field is calculated by the system from the tracking method and preorder settings rather than set directly. In practice you cannot "mark" an item unavailable through that field; you change the quantity or the tracking settings, and the status is derived from them.
Is the 300-item limit per call a problem?
Not for most stores. It becomes a design consideration when syncing a large catalogue at once, because it dictates how many calls the update is split into. It is exactly the kind of documented limit better planned for in advance than discovered on the first production run.
Can missing inventory states be added with a plugin?
Sometimes you can store an extra value, but you cannot always make the platform's availability engine take it into account. That distinction is critical: a value that is stored yet does not affect what gets sold is documentation, not control, and it will not stop an item that is out for repair from being sold.
When is staying on the platform still right?
When your state list is short, one location is enough, and there are no serial-numbered items. In that situation the right investment is in content, photography and the buying experience, not in a data model. A platform that suffices is always the cheaper choice.
Keep reading
Related service
Inventory & Purchasing
SKU-level stock, reorder rules and an approval flow that leaves a record.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.