Changelog

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.

You can now edit the API token on an Amazon integration from its settings. Update the token when Amazon issues a new one, or after rotating credentials, without removing and re-creating the integration.

Shopify still keeps its API token locked, because it is issued through the Shopify install flow and rotating it there would not update Endless.

When a B2B order split into fulfillments going to different destinations, warehouse integrations and EDI documents read the retailer’s PO, vendor, department, distribution center, ship window, and routing straight off the order, so every split fulfillment shipped against the order’s original destination. Each fulfillment now carries its own effective data — its override where one is set, the order’s where it is not — and every warehouse payload and every EDI 856 and 810 scoped to a single fulfillment reads that. A fulfillment with no override produces the same payload as before. Third-party billing carrier can be overridden per fulfillment as well; special instructions stays on the order.

The EDI tab on any order carrying a store distribution has a Store Packout Plan section showing the plan the retailer sent. Items are rows and stores are columns, with the item pinned left and its total pinned right, across three views: As Ordered from the purchase order, As Packed rolled up from every fulfillment’s containers, and Variance between them. Filter by distribution center and store, search by SKU, name, UPC, or purchase-order identifier, and download exactly the view you are looking at.

When the order splits, the plan groups by fulfillment order. Each becomes its own collapsible section headed by its number, distribution center, and store and unit counts, holding only the stores it ships — a purchase order across six distribution centers reads as six sections rather than one 87-column table, and two fulfillments shipping the same store stay apart instead of merging their units. A Fulfillment Order filter appears when the order is split, the CSV carries a Fulfillment Order column, and an unsplit order renders as it did. Two things to know about the numbers: store distribution lines match order lines on the purchase-order line identifier both sides already carry, so any identifier scheme resolves, though orders imported before this change keep the previous matching path; and a quantity that could not be restated in eaches is treated as unknown rather than zero, so it stays out of every total and Variance does not read as a full overage.

Import Order From Integration now covers Endless EDI. Search a retailer’s purchase order number, see the matching 850s with an In Endless or Not In Endless badge, and import one from the same dialog you already use for the other integrations. The retailer’s PO number is the only searchable field — everything else on the vendor side is envelope data, and there is no search into the message body.

An imported 850 runs through the same processing an incoming poll does, so the order lands exactly as a polled one would and the acknowledgement and shipment documents read it the same way. Re-importing an 850 that is already in Endless deduplicates against the existing order rather than landing beside it, and a purchase order that is already an order is skipped, so a partner resending under a new transaction id does not create a second copy.

Automations gain a Process Fulfillment action. Add it to the fulfillment-created trigger and choose what should happen to each new fulfillment: allocate it, mark it ready, or hand it off to the warehouse.

It is a simpler alternative to a fulfillment processing rule rather than a replacement for one. Reach for the action when the same few steps should run on every new fulfillment; keep processing rules for the more involved workflows they are built for. Both take the same steps in the same order, so choosing one over the other does not change what happens to the fulfillment.

A fulfillment that already has a processing rule attached is left to the rule, so the two never both try to move it. When a step fails the completed ones are kept — a fulfillment with no integration lands ready with its inventory reserved and the failed handoff is logged, rather than the allocation rolling back.

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.

Running Update Fulfillments on a Shopify order that had already fulfilled its add-on lines — shipping protection, carbon offsets, and similar non-physical items — errored out instead of reconciling against what was left, so any split, move, or merge spanning the add-on was blocked.

Update Fulfillments now plans against the quantities Shopify still shows outstanding, ignores lines with nothing remaining, and leaves already-shipped add-on lines alone. Two cases that used to give a generic failure now say what to do about them: a partial quantity spanning more than one Endless fulfillment, and Shopify having more remaining than Endless has planned. An unrelated hold on the order no longer blocks a valid plan.

Supply shipments could only be created one at a time. Import Shipments and Export Shipments are now in the table actions menu on the shipments list, mirroring the flow on purchase orders, and the first-run empty state offers Import Shipments so a company with no shipments can reach the importer before there is any data.

The export is import-ready: run it, edit the file in a spreadsheet, and re-import it. Item rows link to a purchase order line by PO Number plus Item SKU, and unit cost, HTS code, and carton data are filled from that line. Container Size, Incoterms, and Cost Allocation are list columns rather than free text, so a raw value cannot leave the shipment unreadable. Shipment status is export-only, because it moves through a validated transition graph and stays a UI action.

The separate product-label and carton-label trays are now one Create Labels tool. Rows can come from selected products on the products list, an uploaded CSV or Excel file, pasted rows, or order lines, and every column on the source can print on the label. A row is matched to a product by SKU or UPC, and an uploaded file is read in the browser rather than stored — the list is a lookup, not data to keep.

The tool adds Code 128 barcodes from any field, multi-across roll stocks with sheet gutters, printing order and rotation options, and retailer identifiers as printable fields, so a label can carry a retailer-specific SKU or UPC alongside the Endless one. Company-wide saved recipes let a label configuration be reused across the team, and can be created, updated, and archived.