Changelog

Endless follows fulfillment changes from Shopify while preserving local work and shipment history. Partial shipments send their tracking to Shopify as they are recorded, so customers can follow each package without waiting for the whole order to ship.

Store owners can connect through a secure invitation link without an Endless login. Existing connections can reconnect to update permissions.

The integration timeline now records each Shopify inventory push: the number of updates Shopify accepted, and any items that were skipped because they are not stocked at their mapped Shopify locations. The details for each skipped item include its SKU, the mapped Shopify location, and the quantity that would have been sent.

Enable the affected items for stocking in Shopify and the next scheduled push will send their quantities. Successful updates and existing retries are unchanged.

Products with components have a new setting that decides whether the components in stock count toward the product’s Available to Sell. It is on by default, matching current behavior. Turn it off on a product whose components you would rather keep for other uses.

Set the choice from the Components tab on the product, or with the bulk editor and product import when changing many products at once. The Components view in the product sheet shows the current setting next to Auto Decompose and lets you edit either one in place.

When components are excluded, Available to Sell drops Available to Make, so the waterfall shows Unallocated Stock minus Ordered. Available to Make itself is unchanged, and allocation and decomposition continue to work the same way.

A routing strategy now says in plain language what to do when its buildings can’t cover an order. Pick one of four shortfall policies on the strategy: ship what’s available and backorder the rest (the default for new strategies), ship what’s available and leave the remainder unplanned, wait until the whole order can ship, or create the fulfillment orders anyway so the warehouse sees the work. Max fulfillments stays a separate control — how many buildings a strategy may split across — and a backorder doesn’t count against it. Each strategy states itself on its list row and at the top of its quickview, so telling two apart no longer means opening them.

A Destinations setting decides how an order’s addresses are grouped: one shipment to a single address, one fulfillment per distribution center, or one per store. It sits above Max fulfillments because grouping decides how many destinations exist and the cap applies within each one. Wholesale orders naming several distribution centers on one purchase order can now split the way the retailer sent them.

Routing rules record which buildings are included rather than a decision about every building in the company, so a building added after a rule was set up no longer lands on that rule’s excluded list the next time anyone edits it. Leftover exclusions clear themselves the next time each rule is saved. The building actions are labelled Include and Exclude, a strategy whose only rule has no buildings is flagged, and every building’s Settings tab lists the rules that can use it.

Placement reads available-to-allocate — the same figure the building menu and order signals show — so an oversold product no longer blocks placement at a building holding unclaimed units, and stock that could be built from components at that building counts. Routing also builds its plan before cancelling anything and cancels only what the plan replaces, so a fulfillment already ingested from a sales channel survives a re-run.

Every existing strategy carries over as it stood, and nothing changes behavior until a team picks a new policy.

Veracore now handles the full supply-shipment loop. A shipment sent to a Veracore-backed warehouse posts as an expected-arrival record, and the key Veracore returns stays on the Endless shipment for reconciliation. Received quantities come back through Veracore’s Expected Arrivals report on the same daily schedule the other warehouse integrations use, and a shipment closes when every line is fully received. Veracore’s owner ID is derived from the System ID already on the integration, so there is nothing new to configure. A missing System ID or Expected Arrival Date is reported before the send is attempted rather than as a generic failure afterwards, and re-sending the same ASN is safe.

Veracore integrations also get a Lot Tracking toggle. With it on, each ASN line sends the shipment item’s lot number as the product version Veracore reads, so a receiving warehouse keeps the lot on record. Pull Inventory branches on the same flag: lot-tracked accounts submit the Product Detail with FIFO report and each SKU version is mirrored into its own warehouse location, with Default Available zeroed so a versioned SKU is not double counted. Non-lot-tracking accounts are unchanged, and a partially versioned account still reconciles — rows with a blank version fall back to a single total on Default Available.

The last-90-days order figure, and the days of supply it feeds, were counting canceled orders. The check meant to leave canceled orders out was looking for a state value the records no longer use, so it matched nothing and let every canceled order through — around 3,240 canceled orders in the last 90 days. Those figures now exclude canceled orders, so recent-order totals and days of supply reflect only orders that still stand.

The inventory export setup copy on Rithum, Walmart, Shopify, Amazon FBM, Skubana, and Faire now names both switches that decide what gets sent: the integration-level permission that controls whether inventory exports at all, and the per-building inventory settings that control which building’s stock counts toward it. The previous copy only mentioned one, so a channel that looked configured to export could still send nothing because no building was included.

Six integrations — Veracore, Infoplus, Jazz, MasonHub, QBO, and ShipHero — showed a warehouse mappings table on their Data tab with no way to add a mapping, so a building could not be pointed at any of them as an inventory source. Manage Mappings only appears for integrations that can fetch their own warehouse list, and Add Mapping was hidden unless an integration opted in.

Any integration without a fetchable warehouse list now shows Add Mapping by default, and the empty state tells you which option to use — Manage Mappings when the integration can look up its own warehouses, Add Mapping with the external code the system sends when it cannot.

Anyone who has tried to answer a simple question like “How many units of this SKU did we sell each week?” knows how much work can sit behind an ordinary chart. First you export orders and line items, then clean them up, join them together, categorize them, and aggregate the result. By the time the data is useful, most of the work has already happened.

ECHO does that preparation inside Endless. It organizes detailed order history into consistent daily records, then uses them to show what was ordered and what shipped over time. Filter by date, SKU, sales channel, or source; compare periods; review channel mix and top products; or open the underlying records to see exactly where the numbers came from.

You can also bring your old history with you. Export the messy detail from the systems you used before Endless, prepare it in ECHO’s simple import format, and upload it. Endless adds new history automatically from that point forward, giving you one continuous view across the systems your business has used.

The prepared data remains visible and usable. Imported records can be maintained separately, adjustments can be added without changing the original orders and shipments, and any filtered view can be exported again. Use the dashboards in Endless for quick answers, or take the same prepared history into a spreadsheet, business intelligence tool, or AI tool for everything else.

Available-to-make on a bundle understated its component every time the component itself was composable and had no physical stock on hand. The rollup was reading each component’s plain “available” number — which leaves out anything that has to be built from its own components — so a bundle whose components had to be made returned zero, and an alias (which gets its whole availability from one component) reported the same.

Available-to-make now measures each component the same way fulfillment does when it decides whether the parent can be allocated. The number on the page and the number a real allocation would use no longer disagree, so a bundle whose components can be built and an alias whose source component can be built both report the units that can actually go out. Nested composables refresh in the right order in a single sweep, so the rollup converges the first time instead of catching up on the next hourly pass.