Changelog

When ShipStation refuses a new order, the timeline entry for the failure now carries the full response from ShipStation under the More details row, alongside the short error message. The visible line stays concise, and the underlying reason — which used to be discarded, leaving customers with only “no orderId returned” — is there when you need to see it.

Extensiv fulfillments used to be marked as fully shipped the moment Extensiv returned a tracking number, so a partially shipped order looked complete in Endless and was reported complete to any downstream sales channel. Endless now records what each Extensiv package actually contained as a shipment on the fulfillment, and the fulfillment stays in progress until every item has shipped. Inventory is committed once every item has shipped rather than on the first tracking number, packages without a tracking number are recorded rather than dropped, and re-polling a fulfillment without changes leaves it alone, so the 15-minute Extensiv poll no longer duplicates shipment activity over its 24-hour visibility window. Miscounted orders can be repaired one fulfillment at a time; orders already reported complete to Shopify cannot be corrected there, since Shopify does not accept shrinking an existing fulfillment.

Extensiv sometimes leaves the SKU off a package content and names the line through its own order item id instead. Endless resolved contents by SKU alone, so those contents matched nothing and no shipment was recorded — the fulfillment stayed in progress after the order shipped, with nothing on the log to say so. A package content now falls back to the Extensiv order item id to find the matching line, where the SKU is reliably present. A content that still cannot be resolved is reported on the fulfillment’s log with its Extensiv line rather than dropped, so a mismatch shows up on the order. A background sweep re-ingests already-stuck fulfillments once the fix is deployed. It checks each candidate against Extensiv’s API, only touches orders that report shipped quantities, paces its calls against Extensiv’s rate limit, and reports throttled orders so the next run picks them up.

Generate Labels on a fulfillment’s Containers tab now produces real scannable GS1-128 carton labels for retailers with a GS1 label mapping. What the button rendered before looked like a carton label and carried no barcode symbology, so a carton sent against it was refused at the retailer’s dock. Labels are requested once per non-archived container on the fulfillment, ordered so the carton number on the label matches the “Container N” shown in the packer’s tab. Fulfillments with no retailer label mapping keep the local label they always used, so nothing changes for anything outside EDI.

Before a batch is sent, cartons without a valid GS1 SSCC are refused and the missing codes become the primary action, so an operator gets a fix rather than a disabled button. When a retailer expects GS1 labels but the account is not set up to generate them, the action blocks and explains rather than substituting a local label the retailer would reject. Once labels exist the menu item reads Regenerate Labels.

The Claim Authority and Reset Order controls are gone from imported orders. You can edit sales-order details, add and change fulfillments, and cancel the order without first taking authority away from its source integration. Fields the source integration manages carry a caution and a save-time confirmation on the fields that use them, so an edit that the source may later overwrite goes through with a warning rather than as if nothing had changed. The fulfillment plan follows the source until a fulfillment change is made in Endless or work begins on it; from that point Endless drives the plan and the activity timeline records the handoff. Canceling an in-progress order cancels every unfulfilled fulfillment order under it, preserves shipments that already went out, and stops the source from restoring the plan on its next pass.

Sales and fulfillment order details are reshaped around the new default. Internal notes live on their own Notes tab with a count badge, and the tab you had open stays selected as you move next or previous through the orders list. The two separate banners at the top of an imported order — one for source-managed ownership, one for fulfillment sync — collapse into a single sync card that names the source, whether it is still sending updates, and whether the fulfillment orders match what the source said. Fulfillment cards default to expanded on active fulfillments and collapse to their items list once fulfilled or cancelled. Advanced view splits an active fulfillment across tabs for Items, Details, Metadata, Timeline, Shipment, and Containers; simple view shows items only. Blockers on a fulfillment list every unmet condition rather than only the next one, with a per-condition Resolve button next to each. The sync card no longer overloads the word “blocked”, and the copy on bulk Reload from source, refresh toasts, and the timeline explains changes in terms of fulfillment orders rather than an internal fulfillment plan.

Shopify keeps sending updates and shipments back after a local change. A Shopify order used to stop accepting webhook updates the moment an Endless user claimed it to route a fulfillment somewhere — cancellations, quantity changes, and other source-side edits were rejected without a trace on the order, and only surfaced later when the mismatch was investigated. Routing a fulfillment no longer takes ownership of the order itself. Shopify keeps sending order-level updates and Endless keeps applying them, while the routed WMS remains the one that reports the shipment. A refused webhook update now shows on the order timeline instead of disappearing, so a rejection is visible where the update would have landed. Canceling an order also refuses up front when one of its fulfillments cannot be modified by the person acting, rather than partially applying and leaving the order in a mixed state. Separately, a Shopify-owned order shipping from a building that had a Default WMS attached was failing to close through Shopify — the warehouse default was being treated as if the order had already been re-routed away from Shopify, and the ship confirmation was rejected on the way back in. Shopify now keeps the fulfillment until you re-route it explicitly or hand it off to a downstream system, so the close-and-ship flow completes even when the building has a Default WMS set; explicit re-routes still transfer control right away.

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.

Royal Mail is now selectable as a carrier alongside the rest of the built-in carrier list. Pick it from the carrier picker anywhere a carrier is set.

A retail EDI purchase order that names a per-store breakdown now splits into fulfillments that carry that plan, and the containers tab knows how to pack against it. Auto-Pack gains a By store (retailer plan) strategy — one container per destination store, pre-filled to the retailer’s quantities, selected by default when the fulfillment carries a store distribution. Before anything is generated it lists shortfalls, identifiers it could not resolve, and units the retailer named no store for. Non-EDI orders and retailers that ship to one destination see no change — the strategy, warnings, validator option, and pick list export all depend on the distribution being present.

Every carton carries its mark-for store as a badge, and a Store column appears on the summary tab. Contents flagged against the retailer’s plan — “Store 0204 expects 25 units”, “Not on store 0201’s plan” — sit on the specific item row that caused them, and the checks aggregate across a store’s cartons so a surplus on one SKU does not offset a shortfall on another. The Validate Containers dialog gains a Pack for Store Quantity option that requires every store’s cartons to match the plan before Close Containers is allowed; the option turns itself off on fulfillments without a distribution and never persists true. Export Store Pick List (DC, Store, SKU, UPC, Product Name, Quantity) is offered whenever a fulfillment has containers, including on cartons an operator assigned stores to by hand.

Rollout note: takes effect per integration once the destination grouping is set on the routing strategy, store codes are added to the integration’s location code mapping, and the trading partner’s live template is updated to emit the store distribution.

Uploading images from the Media library and from a product page now uses the same dialog. The two were built separately and looked and worked differently — different drop areas, different copy, and one started uploading on drop while the other staged files behind an Upload button. They now share the same shape and per-file progress with the filename, and stay a consistent size whether the page already has images or not. The Media library dialog starts uploading as soon as files are dropped, and you can add a second batch before continuing on to link them to products. Freshly uploaded images no longer render as a broken placeholder — 271 images in production across seven companies had been stuck that way — because uploads now match up through the upload request that started them, so the client-side row and the server-side confirmation always land on the same image record. And under the Associated Products heading, the search box now names what you can search on and what happens when you pick a result, so it reads as the way to add an association instead of a filter over the ones already there.

Behind the scenes, image-upload webhooks now record activity through the same path as other actions, so duplicate deliveries no longer create duplicate rows, and image archive and bulk-upload actions show up in the activity feed. Archived timestamps record when the archive happened, so the value stays stable if the record is rebuilt. A few smaller cleanups landed alongside: unused arguments dropped off four of the five media actions that never read them, and a redundant ownership check that the caller already guaranteed came out.

Four updates to creating and importing purchase orders.

Import from the empty state. The purchase orders empty state only offered Create PO, so a company with no purchase orders yet had no way to reach the CSV importer — the import trigger only appeared in the list toolbar, which stays hidden until at least one PO exists. The empty state now has an Import Purchase Orders action alongside Create PO, matching how Products and Suppliers already work.

Month-first dates now import. The importer already advertised MM/DD/YYYY — the default Excel and Google Sheets export — as an accepted format, but read every value day-first. A single such date on a purchase order upload failed the whole file; on demand and historical uploads the same values were silently recorded as the wrong day. All four date-bearing CSV imports now read month-first dates correctly. Day-first values like 25/08/2026 no longer parse, and demand or historical data imported before this fix may carry dates from the earlier misparse.

Ship Date is a purchase order import column. The Ship Date on an existing PO already round-tripped through the export, but the importer would silently drop it on re-upload; it also had no column on new POs, so backfilling historical purchase orders that had already shipped meant hand-editing every one after import. Ship Date is now part of the purchase order import on both create and update rows, and the import UI validates it against the same rules Endless uses everywhere else, rather than whatever the CSV service dashboard happened to be configured for.

The PO Number on a new order is editable. The PO Number at the top of the New Purchase Order drawer is a labelled input. The placeholder shows the number the server would assign next, and the helper text reads “Leave blank to auto-generate”. Type over the placeholder to set a specific number, and the format is validated against your company’s PO number template before save. Leave the field blank and the server assigns the next available number when the order is created, so two operators creating purchase orders side by side each get the next number in sequence. Before this change the PO number rendered as a plain heading — it read like a value already fixed to that order, and the number shown was generated on the client, never sent, and never became the PO’s number.

QuickBooks Online has a new Import All action that pulls your chart of accounts, vendors, customers, items, and payment terms into Endless in one step, so setting up the integration no longer means running each import from a separate menu. Payment terms come in as part of the initial import and no longer appear as a standalone action afterwards. Sending invoices, sales receipts, or product data to QuickBooks before Import All has run returns a clear message that the integration has not been initialized, instead of sending records with missing references and leaving unmatched entries on the QuickBooks side.

Items match to your existing products through whichever product field your item defaults say each accounting field comes from. Tenants whose QuickBooks items are named from the product SKU and coded from the UPC — where the previous match compared against the SKU and then the name and could link almost nothing — now link on the actual mapping. The same rules run in both directions, so a product looked up from the item and an item looked up from the product resolve to the same pair. When two products carry the same mapped value the item is left unlinked rather than attributed to one of them at random. An unlinked product tries to match on demand the next time an operator asks for it, and mass import does the same on the integration-level mapping.