Changelog

The Packiyo integration picked up inventory alongside its order push. Available quantity is pulled from Packiyo on a schedule and on demand, and lands per warehouse: each Endless warehouse that’s mapped to a Packiyo warehouse gets its own quantity, allocated stock keeps being layered in from Endless on top, and warehouses with no Packiyo mapping are skipped.

Setting up those mappings now has its own tool. The Data Mapping section on the Packiyo integration lists the warehouses Packiyo returned and lets you map each one to an Endless warehouse from a single screen instead of hand-editing external relations. Existing setups keep the same shape.

On the shipping side, Packiyo now uses its own carrier mapping when Endless ships an order through it, so only the shipping method name has to line up on the Endless side, and the Packiyo order push carries the Endless carrier service name on each outgoing order. A few API response fields also read back correctly now.

ShipStation and Shopify integrations can now map each Endless warehouse to a specific external warehouse or location, instead of having a single one stand in for everything.

On the Integration Data tab, the Warehouses card has a Manage Mappings action that pulls the live list of warehouses (ShipStation) or locations (Shopify) from the integration and lets you pair them up. Mapped warehouses show their external name in the card; an existing mapping can be removed in place. ShipStation orders sent out for a mapped warehouse now route to that ShipStation warehouse, instead of falling back to the integration’s default. The Shipping Carriers and Sales Channels cards on the same tab were lined up with the new table layout and mapping status badges so all three read the same way.

The inventory CSV import no longer needs an inventory item to already exist for every SKU. If a row references a product that doesn’t have an inventory item yet and has stock to record, the item is created on demand and the stock is adjusted. Zero-stock rows for SKUs with no item are skipped — there’s no point creating an empty record.

Rows whose SKU has no matching product at all used to fail the entire import. Now they’re skipped and every skipped SKU is listed in the import summary, so the rest of the file goes through and you can fix the unrecognized SKUs afterwards. Rows with real data errors (bad warehouse, bad location, bad stock value) still fail the import — genuine CSV problems are not silently swallowed.

This unblocks operators whose products were created in bulk without ever provisioning inventory items.

The Inventory page’s refresh got faster on bigger catalogs and picked up two targeted actions to replace the single Refresh button. The general refresh used to do per-row work that ballooned into hundreds of thousands of small operations on larger accounts; it now runs the same recalculation in a small handful of bulk passes, so big accounts pick up correct counts much faster. Alongside that, the refresh dropdown now offers two targeted actions in addition to the full refresh: Recalculate Inventory Levels and Pull Inventory From Integrations. The two halves can be run independently — useful when only one side needs to re-run, or when troubleshooting which step is responsible for a stale number.

Creating a new product — from the UI, a clone, an import, or an integration — used to do a round of work per warehouse location to seed its starting zero-stock inventory. On accounts with many warehouses and many locations per warehouse that added up to hundreds of database operations per product, which was the dominant cost of product import. It now does the same seeding in a single batch, so the time per product no longer grows with the number of warehouse-locations. Same set of locations gets seeded at zero stock; just much faster.

The fulfillment workspace on an order detail page now shows what you can fulfill with, rather than what exists on paper. Draft fulfillment items show building-level availability, and items made from components show both what’s already built and what can still be built from the parts on hand — hover any of those to see exactly which components feed the count. Decomposed rows are styled distinctly from regular order items so the structure is easy to read at a glance.

The items-to-fulfill table now includes availability, on-order quantity, and how many of each item are still left to fulfill — the same three numbers you’d otherwise have to click around to gather. The building selector also factors in what can be made from components, so it stops pointing you at a warehouse that has the parts but not the finished good.

Across the order, items-to-fulfill, and fulfillment tables, links now point at the inventory item where one exists, and fall back to the product when it doesn’t, so a click takes you to the more useful place.

Decomposition isn’t available on our legacy order system.

The Locations tab on inventory item detail now loads faster on high-volume buildings — previously it could time out — and shows a clearer error/retry state when the underlying query fails, instead of falsely showing “No warehouse inventory found yet.”

The inventory export now opens a granularity dialog so you can choose one row per SKU, one row per warehouse per SKU, or one row per warehouse location.

The active filters on the inventory list are also carried through to the export, so a filtered list produces a filtered export.

Archiving a building now archives its locations and external data instead of deleting them. Inventory adjustments, ASN items, and transfers tied to those locations remain intact, and archiving large buildings — which previously failed outright — now succeeds.

The inventory page now includes a building selector in the top right that filters the table to show counts for the selected location. Multi-select is supported, so inventory can be viewed across any combination of buildings.

Building filters can be combined with product attribute filters on the same page.