Changelog

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.

Six small fixes across the app.

Product sheet: smoother tab switching and scrolling. Switching between the Key Info, Images, and Relationships preset tabs on the product sheet, and scrolling down a catalog with large product photos, used to stutter — every cell was being rebuilt on each tab change and every image in the row was being decoded whether it was on screen or not. Tab switches, quickview open and close, and vertical scrolling now stay smooth: cells reconcile in place instead of remounting, images decode only when they come into view, and the Images column caps at four thumbnails with a +N overflow label so a row with dozens of photos no longer pulls all of them at full resolution.

Order detail tables sort. Two tables on the order detail view sort now. Order items sort by item, price, discount, quantity, or total; fulfillment items sort by product or quantity. Blank values move to the bottom, equal values keep their original order, and sorting is disabled while you are in bulk edit or single item edit, since those modes need to hold the original row order.

Sidebar collapse preference sticks. The sidebar’s collapsed or expanded state sticks across page loads. Toggling by click or with the ⌘\ shortcut saves the choice right away, and returning from a narrow viewport — where the sidebar auto-collapses — restores the last preference you set rather than an older one. The ⌘\ shortcut is disabled inside Settings, where the sidebar always stays expanded.

Date picker: sized right and stays on screen. The date picker’s day-number grid is the same size as the weekday row and the month/year caption above it. Day numbers had been sitting a step larger than everything around them since the shared calendar was inheriting the browser’s default text size, so the fix touches every date field in the app — Purchase Order Issue Date, Shipment Received Date, and every other picker built on the shared calendar. The popover also no longer sits flush against the edge of the browser window. Opening a date field close to the right edge — the Received Date on the Shipment quickview was the reported case — had been clipping the popover off screen; it now keeps eight pixels of padding from the edge on both sides, so even the wide three-month range picker stays fully visible down to iPad mini widths.

Sales channel picker searches and no longer stops at twenty. The sales channel dropdown used across the app only ever loaded the first twenty channels and had no search, so companies with more than that could not pick their older channels from anywhere — and integration data mappings pointing at those channels rendered a raw ID instead of the channel name. The picker is now a searchable list. It shows the twenty most recent channels by default, searches by name against the server, and always resolves the currently selected channel by ID so the name shows up even when the channel sits outside the loaded page or has been archived. Integration Data Mapping tabs read the channel name straight off the mapping, so archived channels and channels past the old cap render with their real names in place of the ID they used to show.

Product confirmation modals: body copy is the right size. The body copy in the Clone Product, Archive Product, and Unarchive Product modals was rendering larger than the modal title above it. All three share one modal underneath, so the fix lands on all three at once. The description now uses the smaller size that matches the rest of the modal.

Archiving a product attribute definition used to update every value on every product one at a time. Definitions with roughly 153,000 values could stall out and roll the archive back, so a large attribute could not actually be archived. Archiving is now a single change on the definition itself and hides its values across every product through that change, so a large definition archives as quickly as a small one.

Clearing a value on a product now removes it rather than leaving an archived-empty record in place. Restoring a definition brings back only the values that still exist, and filters, integrations, unit-of-measure conversion, cloning, and value suggestions all follow the parent’s visibility.

The three product-level costs — Unit Cost, Landed Cost, and Dropship Unit Cost — read as Default Unit Cost, Default Landed Cost, and Default Dropship Unit Cost on the product sheet, the product detail, purchase orders, bulk edit, and the CSV import and export columns. The new name reflects how the value is used: a default that a supplier estimate can override, entered by a person, and blank if none has been set. Gross margin uses Default Landed Cost when it’s present and falls back to Default Unit Cost, so a product with only a unit cost still shows a margin figure.

The Pricing & Costs section on a product separates defaults from estimates. Default Unit Cost, Default Landed Cost, and Default Dropship Unit Cost sit in editable cards at the top. Below them, a Cost Estimates table lists every estimate — your own or from a supplier — with add, edit, duplicate, and archive on each row, a popover for the labor, materials, packaging, freight, and duties breakdown, and a way to promote a single value from an estimate straight to the matching default. Each estimate can carry an effective date, and Current, Scheduled, and Archived badges show what’s live, what’s queued to take over, and what’s been retired. An estimate no longer needs a supplier attached — the question “what should this cost to make?” is stored directly. Profitability at the top of the page is computed from MSRP and Default Landed Cost, falling back to Default Unit Cost if the landed value isn’t set. Completeness for a product accepts either the full stocked cost set or just the dropship unit cost, so a dropship-only product no longer needs a stocked cost to count as complete.

Product Cost Estimates now round-trip through CSV, supplier costs and internal estimates together. Imports create or update by SKU, supplier, cost type, and quantity tier, and carry lead times and cost breakdowns row for row. Row-level errors call out what did not import. Omitting a cost field leaves the current value alone; blanking it clears it. Unit cost is required and must be greater than zero, and effective date is a supported column. Exports respect the current filters on the Products page and produce a file that can be edited and re-imported directly. The Products list Import and Export actions have also been consolidated behind two menus, each opening a dialog that lets you pick Products, Product Cost Estimates, or Relationships. Command palette, table menu, and first-run empty state all point at the new dialog.

The ShipStation ship-notify webhook was reading only the first page of a shipment batch, capping it at 100 shipments per call — anything past the hundredth was dropped with no error and no retry. The webhook now walks every page. Measured in production over the last thirty days, 89 batches exceeded that limit and at least 21,565 shipments never reached Endless. A nightly reconciliation job had been backfilling those shipments once a day, so the missing ones only became visible when that job stopped running. Two guards land alongside: a shipment already recorded with the same tracking number is skipped on repeat callbacks, and voided labels are excluded so a canceled label does not mark an order shipped. When ShipStation reports a shipment that Endless cannot apply to the order, the dispatch step now writes a timeline entry tagged as a ShipStation shipment failure, with the human-readable reason and the technical detail kept apart. Forty-one orders in production had been sitting with the fulfillment marked shipped and the order still in progress, with nothing on the timeline saying why; the run still continues over the remaining shipments and only the failing one leaves a trace.

The ShipStation nightly reconciliation writes a summary log on every run, including runs that find nothing to do, with counters for shipments fetched, orders touched, fulfillments matched, fulfillments reconciled, lookback window, and duration. Fetch failures are logged before they propagate — before, that path sat outside the error handler and left no trace — and each per-fulfillment failure records its own error message. Between 2026-07-25 and 2026-08-02 the job had stopped running and produced the same trace as a healthy no-op run; matched versus reconciled now separates those cases. This change makes the job observable; retry, backoff, and rate-limit handling are separate work.

On a Shopify order, the Fulfillments tab opens with a banner naming who currently manages the fulfillment orders — the source or Endless. When Endless holds the order and you have restructured the fulfillments locally — split one, canceled one, added a new one — an Update fulfillment orders button pushes those changes back to Shopify. The sync runs in the background, the tab re-fetches when it finishes, and the button disappears once both systems match. The button stays disabled while any line has unassigned or over-covered units — a partial set is not something the source can accept — and lists the offending lines so you know what still needs coverage. When a sync fails, order timeline events show an expandable More details row with the Shopify error, the fulfillment order it refers to, and the destination location, instead of a bare failure line.

Fulfillment changes made in Endless — moving items between buildings, splitting a fulfillment, merging fulfillments — did not always take hold on the Shopify side. A structural edit could invalidate the link between the two systems in cases where Shopify could not rebuild its own fulfillment plan, so the change looked applied in Endless while Shopify still held the previous plan. The sync now rebuilds Shopify’s fulfillment orders by moving, merging, and splitting locations until they match Endless, and only rebinds the two together after Shopify confirms. Partial or rejected changes stay visibly unsynchronized on the order rather than looking done, so a divergence is obvious and retrying the sync resolves it. Source-owned changes and integrations that do not sync fulfillment plans behave as before.

The Shopify order reconciliation was reading the same window of recent orders on every run and reprocessing orders it had already handled, which added duplicate fulfillment warnings to the timeline for the same underlying condition. Each successful run now moves its start point to when that run began, so the next pass reads new activity forward from there instead of re-reading everything since the day started. A failed run holds its position, so nothing is skipped. Webhook handling is unchanged.

On the standalone fulfillment order page, the fulfillment card was missing details it correctly showed when the same fulfillment was opened from its sales order — cancellation warnings, the failure banner, draft actions, the lifecycle stepper, and shipped tracking. All of these now appear on the standalone page too. Nothing changes when the fulfillment is opened through its sales order.

Fulfillment orders now carry the dropship workflow end to end. When a fulfillment has a supplier, you can capture and edit unit costs, line totals, and shipping and other charges on the fulfillment itself. Assigning or updating a supplier can optionally refresh line costs from the supplier’s dropship cost tiers with a fallback to the product default; keeping the option off leaves costs untouched, and any line with no matching cost is cleared rather than left stale. Costs travel through to the fulfillment PDF and the public share view, including a supplier cost summary. The public share header no longer shows the sales order number.

A new Email Fulfillment Order action sends the share view directly from Endless. To and CC recipients are separate, each address gets its own revocable link, and the dialog suggests every supplier contact with an email, the building’s email address, and the current user, so the right recipients are one click away. Buildings now hold one primary email address, editable from a Contact Information card on the building’s General tab and reachable from the fulfillment email dialog. Delivery goes through SendGrid and retries asynchronously if it fails.

Companies with a GS1 licence can now manage their prefixes in Endless and assign UPCs from them to products, without hand-typing codes or tracking a spreadsheet on the side. Each prefix records its item-reference space, so the number of codes still available comes straight from what the licence actually grants, and Endless will not mint the same code twice or hand out a code that falls inside another company’s prefix. Blocks of assigned codes can be exported to CSV.

UPC assignment lives on the product. Clearing a UPC keeps other product fields untouched, and the app asks whether to release the code back to the prefix once the product has moved off it — kept as a separate step because GS1 does not allow a released code to be reused. Product packaging can also carry GTINs, tied to the same prefix rules. The feature is in early access and available on request.

Three updates to Suppliers.

Archived suppliers show as Archived. An archived supplier used to still show Active or Inactive on the list and detail page, because archiving only marked the record archived and left the underlying status alone. The badge now shows Archived when the supplier is archived, so the status column matches the detail page. Archiving from the detail page or quick view also keeps the page open, so the archived banner and the Archived badge update in place instead of the view closing.

Suppliers carry a Legal Name alongside their display name, so the name that appears on paperwork and accounting records does not have to be the same one shown in the app. Legal Name is available in the Add Supplier dialog, editable from the Company Details card on the supplier’s detail page, and shown as a sortable column on the Suppliers list. Optional throughout — empty renders as an em-dash — and searchable from the Suppliers list search box. The existing Supplier Name column and the Edit Name action have been renamed to Supplier Display Name and Edit Display Name, so it is clear which name a screen is reading.

Supplier–product relationships now come from product costs. Adding a product cost for a supplier creates the relationship on its own, and archived relationships are restored on the same signal. Purchase orders no longer create these relationships as a side effect, so a purchase order for a supplier that has never quoted a cost for a product does not link the two. Imports keep the supplier’s minimum order quantity intact: the supplier link is created before its costs, so the imported MOQ is not overwritten by the default. Purchase order line lookups read cost and MOQ from the supplier relationship directly.

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.

The fulfillment order list has two new filters that reach through to the parent sales order: Sales Order Created Date, with the same range presets as the sales order date filter, and Sales Order Tags, which multi-selects across the tags on the parent order. Both compose with the existing fulfillment order filters, so you can, for example, look at fulfillments for last week’s VIP-tagged orders in one view.

The bulk actions on the Orders list now respect V1 and V2 order versions. Select V2 orders and the toolbar offers Create Fulfillments, Approve, Reload From Source, and Resend Shipment Updates. Select V1 orders and the toolbar offers the full V1 action set. A mixed selection shows both menus side by side, each labeled with how many of the selected rows it applies to, so a V1-only action never fires on V2 rows and vice versa.

Reload From Source and Resend Shipment Updates now open a confirmation dialog before running — the Resend dialog names its scope, so you know the resend covers every shipment on the order. Reload From Source is also hidden when the source integration does not support reload, so it will not appear next to orders it cannot help. Selection now clears when you change page or page size, since the same rows are rarely still on screen.

The Orders list no longer dims or shows a page spinner when a new order arrives or an existing one updates through the live feed. Those refreshes run in the background and swap rows in place, so the table you are reading does not blink away. Manual refresh — the refresh button in the toolbar — still spins while it runs. The old new-orders badge counter is gone; the list picks up new orders on its own.

Product attributes can now be archived and restored, the same way products, suppliers, and images already can. Archived attributes drop out of the default attributes list; a filter at the top of the list includes them alongside active ones or shows them on their own, each carrying an Archived badge. Opening an archived attribute lands on a read-only detail view with a Restore action and an Archived banner at the top. On a product, an archived attribute keeps its tag with an archived treatment, and the edit toggle switches to a View details link that opens the same read-only view.

Creating a new attribute with the same name or handle as an archived one now says exactly that — an archived attribute already uses this name, restore it instead — so an operator does not silently mint a duplicate. The archive confirm dialog also reads correctly in both directions now: it was only offering Archive, and now offers Restore when the attribute is archived.

The company-wide feed of human-written notes on entities is now called Updates. In the system sidebar it reads Updates rather than Activity, and its page has moved from /system/activity to /system/updates. Bookmarks pointed at the old URL will not resolve.

Activity is now reserved for system-generated logs — the ones on entity detail pages and the Recent activity card on the dashboard — so the two feeds are named for what they are. Same notes, same replies, same feed.

New fulfillment order numbers can now follow one of three formats. The default keeps today’s shape: the order number followed by -FO- and six random hex characters, like SO12345-FO-4414A3 (a small change from the five hex characters used before). The two other options are SO12345-FO1, an order number plus a per-order sequence, and FO-4222A3, a plain code with no order prefix.

Pick a format under Settings → Creating Fulfillments → Fulfillment Order Numbers, and it saves the moment you select it. The choice applies to fulfillments created from then on; existing fulfillment numbers are never rewritten. Downstream systems that treat the fulfillment number as an opaque identifier keep working across the change.

When product photos are hosted on Shopify, the product sheet, table, and grid now ask for the thumbnail size the cell actually renders at, instead of the full-resolution original. On a catalog of print-resolution photos, page one dropped from about 13 MB of image transfer to about 270 KB, and the browser is decoding roughly one percent of the pixels it used to.

Photos hosted on our own storage or on Cloudinary are unchanged; those fall through to the original as before, and the separate variant work covers them.

A Recent activity section at the bottom of the dashboard lists what’s happened across the company — order changes, product edits, inventory movements, integration events — with each entry linking to the record it came from. The list scrolls back through older history instead of stopping at a fixed count.

The Activity card on individual orders and products keeps the same behavior, and now scrolls into older entries the same way.

Ship orders sent from Endless to Business Central now expand bundled SKUs into their component SKUs, the same way accounting exports already handled bundles. A bundle no longer arrives as a single parent line the receiving Business Central job did not know what to do with.

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.

Jazz OMS is now a connected fulfillment channel. Endless sends orders to Jazz for shipping, reads ship confirmations back on its own, and syncs inventory in both directions. A webhook installs on connect so ship notifications arrive as they happen.

Product exports now finish for the largest catalogs. The export was loading every combination of image, tag, and attribute row into memory before writing the first row, so a company with a few hundred products was pulling in more than a hundred thousand rows and the worker ran out of memory. The request would sit in Processing and then disappear from the list.

Five companies had exports that never completed since May. Those same catalogs now export in about a second. The row counter is also wired to the same progress update every other export uses, so the request no longer times out after fifteen minutes and vanishes while the job is still running.

Sales order line quantities can now be edited, one at a time or in bulk, after part of the line has been fulfilled. Quantities can drop as low as the amount already allocated or in an active fulfillment, and can be raised freely above that. Before, any fulfillment activity locked the line.

Two updates to the ShipBob integration.

Webhook subscriptions are set up automatically once the OAuth handshake finishes, so updates from ShipBob start arriving without a follow-up step. Advance shipping notices — ASNs from an inbound purchase order shipment — flow through to ShipBob the way the other WMS integrations already worked, and each box on the ASN carries its line items resolved from the source ASN, so warehouse staff no longer fill in box contents by hand. SKUs ShipBob does not have on file are dropped from the send with a warning in the system log, and on completion the shipment is marked received rather than closed — matching the other WMS integrations.

The warehouse mapper shows one row per building. ShipBob’s location id already carries the fulfillment id, so fulfillment centers and locations are treated as one set now, and one mapping covers both outbound orders and inbound receiving at the same building.

Walmart inventory refreshes had stopped reaching Walmart. The stored access token was expiring and the refresh was pushing anyway, so quantity changes were not being applied at Walmart. The token now reissues before each refresh, and inventory updates reach Walmart again.

Outbound 855 acknowledgments got two corrections that make them line up with what the retailer actually reads.

Lines can be acknowledged in the partner’s own unit. Whole Foods orders in cases, Endless stores in eaches — an outbound 855 template could only echo back whatever unit the 850 arrived in, so there was no clean way to acknowledge a line back in the partner’s code, and no way to state a corrected quantity in it either. Templates can now ask for the acknowledgment on a specific basis (“each”, “inner pack”) and the code the partner uses for that basis is pulled from the integration’s UOM mapping — so renaming CA to CS for one partner is a one-token change on the mapping and needs no template edit. The same pass fixed several ways an acknowledgment could tell a retailer we had dropped a line they ordered (two lines of the same SKU collapsing, archived or unresolved products disappearing, partially numbered purchase orders cancelling their unnumbered lines).

The header now agrees with the detail. BAK02 — Amazon’s mandatory “acknowledgment type” field — was hardcoded to AD (“completely accepted”) on every 855, including ones whose per-line ACK segments rejected a line or cut a quantity, so the header was contradicting the detail on exactly the orders where the detail mattered. The header now reads AC (“cannot be fully accepted”) whenever any line was rejected or short-shipped, and AD only when every line came back accepted.

Order status changes used to leave no mark on the timeline. Only the creation events and fulfillment moments were being subscribed to, so an order moving out of Pending — whether by auto-accept, an automation rule, or a person — showed up with an empty history. An EDI order that reached “Ordered” with nothing on its timeline is what surfaced this.

Eleven lifecycle events now write to the timeline: accepted, released, cancelled, held and released from hold, completed, duplicated, and the rest of the transitions the order aggregate can apply. Holds carry their reason and release note into the message, so the timeline records why an order stopped rather than only that it did, and cancellations and holds render in red, completion in green, the others in neutral. The activity feed also picks up a lifecycle chip treatment: a status-change row reads “Status Pending → Ordered” as two coloured chips instead of a plain sentence.

Every sales channel has always had an auto-approve setting — it controls whether an integration-sourced order that lands in Pending gets advanced to Ordered on its own — but the toggle had been missing from the settings page for months. The value was reachable only through the database, so a channel that was auto-approving orders, or not, had no way to show which in the app.

The toggle is now on each sales channel’s settings card, reading and writing the same setting that has been driving behaviour all along. Nothing about how auto-approve works changes; the switch is just visible again.

The public tariffs estimator at tariffs.endlesscommerce.com was still doing pre-February duty math against a 2026 HTS Rev 9 schedule, so anyone running a Rev 14 entry through it saw IEEPA duties that no longer apply and missed the Section 122 surcharge and the July 24 forced-labor tariffs entirely. Since customers use this to estimate what they’ll pay at the border, stale numbers were wrong numbers.

The bundled schedule, duty engine, and news feed are now on Rev 14 with the current post-July regime, and the Updates tab reflects the change.

Two ShipStation problems landed together.

Orders now route to the mapped building. ShipStation was ignoring the building each order was mapped to and dropping every order onto the store’s default Ship From Location — so a parcel could ship with the wrong return address and be rated from the wrong postal code, and nothing in the logs said anything had gone wrong. The mapping now takes effect: orders land in the right building, and if a mapping is set but doesn’t hold a ShipStation ID, the fulfillment fails cleanly instead of silently shipping from the wrong place. That failure is easy to correct — repair the mapping and re-send — whereas a wrong-address label already at the printer is not.

Ship notifications come through from every store on the account. The webhook subscription had been pinned to one store per integration, so any store a sales channel routed orders into produced no notification and only reached Endless via the nightly poll, up to a day late — and if that one poll failed, the shipment slipped past the lookback window entirely. Subscriptions are now account-wide; each fulfillment is matched to its owner by order ID, and shipments from other tenants are ignored the same way they always were. Existing integrations get resubscribed automatically on deploy.

Export download links in the inbox used to look active forever, but the underlying signed URL only lives a few minutes. Clicking one after it expired sent you to an S3 error page with no clue why.

The notification now carries the link’s expiration alongside the URL, and the inbox reads it: an active link opens as before, an expired link renders disabled with a short “This link has expired” note, and clicking it raises a toast telling you to re-export. Fixes the report that operator-role accounts couldn’t get an inventory export to actually open.

Unit Cost, Landed Cost, and Dropship Unit Cost are now three clear, distinct fields on every product — editable from the product page, the Costs product sheet, or CSV import. Purchase order lines and dropship fulfillment lines default to the right cost automatically, and margin uses Landed Cost with Unit Cost as a fallback, so an incomplete cost is never shown as profitability. All three carry their full precision everywhere they’re shown, including the product sheet.

A unit cost entered on a shipment’s Financial tab was rounded to two decimals on the way in and read back from a two-decimal display string, so a per-unit price like 1.234 lost its third decimal on save — even though the same value survives unchanged on a purchase order line. The shipment tab now uses the same precision the PO line-items table already uses: up to four decimals, which is the most Endless stores for money.

Everything under two decimals still renders at two, so a $12 cost still reads as $12.00 rather than $12; a $0.00 cost keeps showing as $0.00 instead of “—”. The By HTS breakdown that reads from the same value gains the same precision.

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.

Fulfillment orders now have Containers — a real record of how you packed the boxes, pallets, or master cartons that leave your building, one line at a time. Open a fulfillment, add a container, drop items into it, print its label with the shipping container barcode, and mark it closed when the packout is done. Create as many as the shipment needs, and edit or delete a container after the fact if you catch a mistake — you’re no longer stuck with whatever the first save recorded.

Container barcodes (SSCCs) are minted by Endless from your GS1 prefix at save time instead of being generated in the browser, so they’re valid, unique across your company, and stable across reloads. The container’s type — carton, inner pack, master carton, pallet, or generic — is derived from what’s inside it when you close it, and the person who created it is recorded on the record. A container whose barcode isn’t valid GS1 is still saved with a warning rather than rejected, so a scan-in-progress packout doesn’t get blocked at the wrong moment.

ShipBob joins the set of connected fulfillment integrations alongside ShipHero, MasonHub, Veracore, and ShipStation. Connect from Integrations with a personal access token or OAuth; the integration comes up with the writable channel already set, and its fulfillment centers appear in the warehouse mapping picker so you can point Endless buildings at them.

Once mapped, DTC, B2B, and dropship orders push through with retailer program data and third-party billing already in place, and per-order channel routing follows your sales-channel mapping. Fulfillment-level gift messages take precedence over the order-level value on the way out. Shipments come back through ShipBob’s webhook by default, with a scheduled poll as a fallback, and the resulting cartons — with tracking, dimensions, and the line breakdown per carton — land on the shipment page. Sending an ASN opens a work-receiving order in ShipBob and a follow-up cancel on your side cancels it there too. Pulling inventory paces itself against ShipBob’s rate limit so a large sync doesn’t crowd out other work.

The Financial tab on shipment detail is rebuilt. Shipping costs assigned to a shipment are now distributed explicitly to line items and saved on those items, and single-shipment saves go through synchronously — the page reflects what’s saved right after you save, instead of catching up on a background pass. Per-category duty assignment is atomic: a category is either fully assigned or not, so the totals no longer disagree with the item breakdown mid-save.

Underneath, the parallel system that recomputed cost allocations at read time is gone, so what you see on the item is what’s stored on it. The tab picks up a cleaner assignment panel and cost-items card, and a bulk-edit path for adjusting costs across many items at once.

Archiving a supplier no longer breaks anything that references them. An archived supplier still shows up wherever they’re linked — purchase orders, order fulfillments, products, and supplier contacts all keep the supplier’s name and details instead of going supplier-less. Their own detail page still marks them as archived.

You can still edit an archived supplier’s record, and a PO whose supplier is archived still falls back to the supplier’s email when there’s no other contact on file. Adding a new line item to a PO with an archived supplier no longer tries to create a fresh product-to-supplier link behind the scenes — the line item is just added.

The Fulfillment Orders list has a new Apply Rule action. Select the fulfillment orders you want, pick one rule, and apply it to all of them in one go. The batch runs in the background — the app stays usable while it works instead of blocking for the twelve-or-so seconds each fulfillment order used to take.

Progress shows in the list toolbar while the batch runs. Fulfilled and canceled fulfillment orders are filtered out before it starts; anything that couldn’t be processed once the batch is running — wrong company, archived, or already past the point of accepting a rule — is listed with the reason when it ends. Up to 200 fulfillment orders can go through in one batch.

Filtering the Sales Orders list by the Items filter with more than one product used to return the same order once per matching item, so an order that contained two of the products you’d picked came back twice — and the total at the bottom of the page counted rows instead of orders. Fulfilling one order could drop the total by two.

Each matching order now comes back once, the total matches what’s on screen, and paging back and forth is steady. The Items filter on the orders CSV export picks up the same behavior. Sort order also gets a stable tiebreaker, so orders that share a sort value (same ship-to name, same status, same import timestamp) no longer drift between pages.

Purchase Orders have a new optional Description field, so you can label a PO with something you’ll recognize at a glance — “Q3 fall reorder — hoodies” — instead of relying on the PO number alone. Up to 255 characters.

The PO list keyword search matches on Description as well as PO number and item SKU, and the standard and complete PO exports pick up a Description column.

Suppliers can now be archived, the same way warehouses already can. Archiving hides a supplier from the default supplier list and pickers while preserving every historical link — purchase orders, product relationships, receipts — untouched. It is fully reversible.

Archive lives on the supplier detail header. If the supplier still has open POs or linked products, the confirmation shows those as advisory warnings but leaves the button enabled — the pattern is warn, don’t block. Archived suppliers get a top banner with a one-click Unarchive. The suppliers list picks up an Archived filter (Include archived / Archived only), and the default view hides archived rows.

Fulfilling many orders at once is faster. The job that runs each order’s allocation and fulfillment used to repeat the same database work for every order it processed; that cost added up during large bulk fulfillments and kept database locks held longer than necessary. That redundant work is gone across inventory allocation, fulfillment materialization, and the fulfill command’s order validation. Nothing changes about what fulfillment does — just how much it does per order.

Two same-week fixes to how DSCO orders come into Endless.

The reference-number and customer fields were slightly off. The customer reference number on imported DSCO orders now uses the retailer’s consumer order number when it’s there (falling back to the DSCO order id if not), and the retailer id lands on the customer name field instead of the trading-partner name. Existing orders aren’t rewritten — this fixes new imports going forward.

Separately, every DSCO order created an empty B2B-data record even when there was nothing to store. That row is gone; B2B data is only written now when there’s a retailer id to put in it.

The Create Purchase Order drawer used to open with the entire supplier list expanded, pushing the Products and Notes steps below the fold. Now:

• The supplier list starts collapsed to the first five, with a Show more / Show less toggle — the same control the shipments list uses. It resets to five when you start a new search.
• Picking a supplier collapses the Supplier step and opens Products automatically, so the flow reads top-down (Supplier → Products → Notes) and the later steps stay in view without scrolling.
• Products uses the same standard Show more toggle instead of the old full-width “Load more products” button, so the drawer looks consistent step to step.

Shopify imports now let you pick where the Note from Customer on a Shopify order lands: Instructions (default), Gift message, Both, or Neither. Set it per-integration under Shopify → Orders in the integration settings.

Before this, the note always went to the order’s Instructions. Stores that treat the customer note as a gift message never received it; stores using it for PO / handling instructions were fine. The new setting fixes both directions: pick Gift message and the note lands there instead, pick Both and it’s written to both fields.

Each mode only writes the fields it names, so switching modes never overwrites data in the other field. The audit line on the order timeline (Note from Shopify: …) is preserved in every mode.

The “Tariff Calculator” link on a product’s Customs Information card now opens the in-app Tariffs tool for companies with the tool enabled, instead of the external tariffs site. The external-link icon on the link only shows when it still points at the external site.

You can now remove a product image from the DAM. In Manage Images, each image card gets a Trash action, and the sidebar exposes destructive Archive Image / Archive Images actions for single and multi selection. Pick one or many, confirm the archive dialog, and they’re removed from the DAM; unsaved edits are guarded before the archive runs, and the grid refreshes when it’s done.

Underneath, archiveImage soft-deletes the image and cascades the cleanup — the original is archived, every image variant is archived via the same cascade, and every image_relationships row pointing at it is destroyed in one transaction. Guarded by media:update_image and scoped so an image belonging to another company is rejected before anything is touched.

Bulk editing items on a sales order was refusing to save whenever any existing line on the order had no product or SKU on it. That treated a saved line as invalid, so the Save button stayed disabled and no other edits on the order could be applied. Existing lines now validate by their order-item id, so a saved line without a product no longer blocks the rest of the changes. Newly added lines still require a product or a SKU.

Bulk uploading product images was sometimes finishing with fewer thumbnails than the number of files you had selected — a record was created for each one, but a couple of tiles never rendered. Files being uploaded in the same batch are now given unique upload names, so two files that happen to share a filename no longer collide on upload, and the file key that we save on each image matches the actual location the file was written to so its thumbnail resolves.

A handful of dates were displaying a day early for anyone west of UTC — date-range filter pills across every list, EDI ship windows on the order detail, and Purchase Order issue / expected / last-purchase dates on supplier detail, the suppliers list (table and grid), and the product purchasing table. The stored values were fine; only the rendered display was shifting.

Those dates now render as calendar dates, so a date without a real time reads the same day regardless of the viewer’s timezone. Filter pills route through the shared filter component, so every date-range filter picks this up at once. Purchase-order delivered_date, which carries a real timestamp, is unchanged and still displays the local time.

Automations can now set fulfillment details automatically when a new fulfillment lands. Pair the new “Set Fulfillment Dynamic Field” action with the “fulfillment created” trigger, pick a field, and set the value once — every fulfillment created under that rule picks it up.

Four fields are supported: instructions, gift message, third-party billing (on/off), and carrier service. Carrier service routes through the shipping-instructions update path so the requested carrier name and id land together; the other three go through the fulfillment-details update path.

Some accounts saw Incoming quantities on inventory items despite having no open Purchase Orders. Closed supply shipments that had never been received were still being counted as inbound. Incoming now excludes closed shipments everywhere the number is shown, so what’s listed as incoming is only what’s actually coming in. Roughly 708,000 units across 28 companies drop out of Incoming as a result, and the Unassigned row in the fulfillment quickview stops going negative on the affected accounts.

Internal notes on Sales Orders, Purchase Orders, and Shipments can now be edited. Each note you wrote shows an Edit action that opens the same dialog you used to add it, prefilled with the current content. Saving updates the note in place and marks it with an “(edited)” indicator so anyone reading the timeline knows it changed since it was posted. Only the note’s author can edit their own notes; everyone else’s stay read-only.

A handful of independent permission gaps had operators bumping into the same generic Not authorized to perform this action error across V2 order screens, a couple of settings pages, and shipment-driven accounting updates. They’re all fixed — operators can walk fulfillments forward from the quickview, the Create EDI Transaction modal and its neighbours open again, and later shipment updates on the same order refresh the QuickBooks financial instead of silently drifting.

If you were still seeing a Not authorized message on the Orders list, that one appears to be a request arriving with the wrong company context rather than a missing permission — still under investigation.

Alias is now a product type alongside Base Item, Bundle, and Part. Reach for it when a legacy or external identifier — an old SKU your customers still order under, a channel’s catalog code, a vendor part number — needs to point at the real product without duplicating its data. An Alias is defined by its components, so it inherits its price, weight, dimensions, and imagery from what it stands for.

Alias shows up everywhere Bundles do. Create and edit Aliases from the product form with the same component manager (Base Items and Parts are valid components, and the quantity stays as guidance rather than hard enforcement so alternate-unit aliases are workable). Filter by Alias in the product list, inventory views, and Purchase Order product pickers. Import Aliases through product imports, and target them in bulk edit. The identity styling and badge make Aliases easy to spot at a glance in lists and on the product sheet.

Available-to-make inventory keeps up with Alias just like Bundles. Adding, changing, or removing an Alias’s components immediately recalculates its available-to-make, company-wide inventory recalculation includes Aliases, and removing the last composition line clears its available-to-make cleanly. Orders decompose Aliases through the same composition path as Bundles, so fulfillment picks the underlying components.

Sometimes an order ends up stuck on the wrong integration — the store’s old connection was replaced, or the integration got reconnected under a fresh record and the order is still pointing at the archived one. It can now be moved.

Open a V2 order and choose Assign source integration (or Change source integration) from the action menu — the command palette has it too. Pick another live integration for the same store from the picker, confirm, and the order is repointed. The new integration takes ownership and, if it supports it, refreshes the order data on its next pass.

A few guardrails so nothing surprising happens: the order has to be claimed locally (not currently owned by another integration), it needs an external order id, and it can’t have active fulfillments. If any of those aren’t in place, the dialog spells out what to fix. Reassignments have to stay within the same integration type. Admin, operator, and order-receiver roles have the permission by default.

Alongside this, skipped Shopify order updates and unsupported order resets now show the actual reason on the order timeline — “authority not held”, “no warehouse”, “reset unsupported” — instead of a generic error.

Searching for a product to add to a Purchase Order, a Supply Shipment, a bundle, an echo SKU, or from the command palette now returns results quickly on very large catalogs — pages that used to time out and show “No products found” on accounts with over a hundred thousand products come back in a fraction of a second. Name and SKU search return the same products as before, just fast enough to actually use.

Purchase Order and Supply Shipment detail pages load faster across the app, and the improvement is biggest on large documents — pages that used to take several seconds now open quickly no matter how many line items they have. Product names, images, and cost totals appear together instead of trickling in row by row, with no change to the numbers themselves.

Report Issue — the action for flagging an operational problem on an order, which tags the order, adds a note, and can alert your ops team in Slack — can now reship in the same step. Tick “Reship order?” in the Report Issue dialog and the button becomes “Report & Reship”: the report is filed, then a Duplicate Order dialog opens already filled in, with the new order number suggested as the original plus an -R suffix and a reship tag applied (for example, OPS - Reship - No Movement).

Duplicate Order also gains more control at every entry point, including reship: a sales channel selector — defaulting to the source order’s channel, so you can send a duplicate to a different channel and keep channel reporting clean — and an additional-tag field that adds a tag to the copy alongside the ones it carries over. Reporting an issue also works on every order now; it had been failing on some newer orders, and that’s fixed.

The Supply Shipment detail page is refreshed to match the Purchase Order redesign. Destination is an always-available sidebar selector — building, location, or a custom destination — that saves automatically, and closed shipments show it read-only. The item table folds the product image into the details column, keeps the purchase-order grouping, and moves sorting into Actions → Sort. Status changes live under a single “Change Status” action with everything else in a three-dot menu, and the tabs are more compact, with document and note counts and a dedicated Notes tab.

You can switch a fulfillment’s fulfillment integration directly from the fulfillment. A small edit modal lets you pick a different integration and save without dropping into the underlying order or rebuilding the fulfillment. Useful when an order lands with the wrong integration attached and needs to move without a full recreate.

The Fulfillment Orders list opens quickly now, even for companies with a huge number of fulfillments — on the largest accounts it went from tens of seconds to roughly a tenth of a second. Only the page you’re looking at is loaded, rather than the whole company’s fulfillments, and the rows appear as soon as they’re ready while the total count fills into the pagination bar a moment later. The header count is the real filtered total, blocker details load when you open a status instead of on every page load, and switching sort stays fast.

Ordered-quantity calculations return much faster for products with a lot of order history. The query for a hot SKU used to take around 20 seconds and get worse under load; it now takes about 7 seconds with the same results. The V2 unassigned-quantity calculation also stopped joining every warehouse just to zero most of them out — totals are unchanged, it’s just less work per call.

You can now sort the line items on a purchase order. Open Actions → Sort, pick a column, and choose ascending or descending.

Supply shipments now pass through a Received step between In Receiving and Closed. WMS integrations (Extensiv, Gobolt, Infoplus) mark a shipment as received automatically once the downstream system reports receiving complete, so the shipment no longer jumps straight to closed while receiving finishes. Closing is now a deliberate manual step from Received, which keeps Closed as the finalized state you commit to when you’re done.

The timeline, status badges, filters, and shipment status groupings all pick up the new step. Cancelling from In Receiving and Received is allowed. A shipment needs at least one item and a destination to enter Received.

The Purchase Orders list has a status filter — draft, issued, in production, in transit, delivered, closed, canceled — matching the status lifecycle the PO detail page already used. The old “approved” filter, which never quite worked, is gone.

Creating a new fulfillment on a Shopify order no longer fails when the order has an archived fulfillment sitting behind it. The next per-order fulfillment index now looks across archived rows too, matching the database uniqueness rule, so the new fulfillment picks an unused index instead of colliding.

Cmd-K (Ctrl-K on Windows) now opens a global palette across the app. It searches actions, navigation, and recently-viewed entities from anywhere. Anything you can trigger with a button on a page shows up in the palette too, grouped under “On this page” for the entity you’re looking at, so common actions — duplicate an order, change sales channel, link a product — are one keystroke away. Destructive actions still go through their confirm modals; the palette is a faster way to reach an action, not a way around the safety net.

To use it, press Cmd-K from anywhere and start typing. The palette filters as you go across three kinds of result: actions for whatever you’re currently looking at (grouped under “On this page”), places to navigate to, and records you’ve opened recently. Arrow keys move through the list and Enter runs the highlighted result, so you can jump to a record or fire a common action without leaving the keyboard or hunting for the button.

You can now set up a Custom Product Integration to write catalog data into Endless the same way our built-in product connectors do. It behaves like a Custom Sales or Custom Fulfillment integration — Endless provisions an access token, API key, and API secret — but the scope is product data: attributes, media, and inventory. Use it to feed the catalog from a system we don’t have a first-party connector for, without a bespoke build. It shows up under Custom Integrations in the integrations picker alongside Custom Sales, Custom Fulfillment, and the Read-Only Data Integration.

The fulfillment creation experience on a sales order is now one coherent workflow. A single Create Fulfillments menu offers three ways in — Choose Building, Use Strategy, or Add to existing — and item selection has moved into the creation dialog itself, defaulting to all unassigned items with per-line quantity editing, removal, and building-specific availability shown inline. The menu stays hidden while the order is still a draft.

Automations are surfaced before they run: creating a fulfillment, applying a routing strategy, or assigning a fulfillment rule now warns you about active automations that will fire as a result, so nothing runs behind your back.

The “Not in Catalog” status badge on an order item is now clickable and opens the Link Product action directly. Before, that action lived behind the item’s edit menu and then a three-dot menu, so most people never found it. Clicking the badge takes you straight there.

Supply shipment items now carry a lot number, so one PO line can be split into multiple shipment rows — same SKU, different production batches — each with its own quantity and its own lot. Assign lot numbers when adding items to a shipment, edit or split an existing line across lots, and filter shipments by lot number from the list. Lot-aware product costs surface on rows where they’re relevant. Coverage math sums per lot bucket, closing a case where two lots on the same PO line collided and one row’s quantity silently vanished from the totals.

WMS/ASN payloads and lot-aware inbound sync aren’t wired yet — those follow once the WMS side sends a lot identifier.

For EDI orders, the EDI document list, create, and deliver flows now have their own “EDI” tab on the order page, alongside Sales Order, Fulfillments, and Timeline. Same documents and actions as before, just easier to find. The tab appears only when the order is actually an EDI order — other orders don’t get it. The old hidden /edi URL, which nothing linked to, is gone.

You can now save an automation with no conditions. The rule applies whenever its trigger fires, without needing a placeholder condition to satisfy the form.

A fulfillment stuck in Failed To Fulfill can now be cancelled. Cancelling first walks the fulfillment back to draft so allocation unwinds cleanly, instead of erroring on the state check and stranding the fulfillment.

You can now create a Custom Data integration that reads your Endless data — products, prices, orders, inventory, warehouses, purchase orders, suppliers, customers, accounting, ASNs, automations, and more — without being able to write anything. Set it up from the Integrations page, hand its credentials to a reporting tool or a data warehouse, and it sees your data end-to-end but can’t change it.

The role is scoped to your company. It can’t reach other tenants’ data, and it doesn’t have access to sensitive internal surfaces like other integrations’ credentials or staff PII.

“Fulfillment Profile” is now “Fulfillment Rule” throughout the app, and rules are no longer required to process a fulfillment. A draft fulfillment can be allocated manually or have a rule applied — either works, and nothing forces you to attach one to move forward.

The fulfillment settings screens got a pass too: language across routing strategies, rules, and profiles was tightened to match how the ops team actually talks about it, informed by interviews with people who live in these screens.

Resetting a Shopify order previously left the order with no fulfillments when it already had a cancelled one. Reset only unhooked active fulfillments from the identity index, so the cancelled fulfillment’s Shopify FulfillmentOrder link stayed live — the replay then resolved the FO back to that dead fulfillment and no-oped instead of rebuilding a fresh one.

Reset now clears the identity link on every non-archived fulfillment, cancelled or not, and the replay rebuilds reliably.

Resetting an order — handing authority back to the source integration and rebuilding the order from what the integration currently says — is now available from the order page. The underlying reset flow shipped earlier; this puts a control on it so you can trigger it without a console.

Purchase-order notes now live in the same Internal Notes system every other object uses, so the notes card on the PO Details tab behaves the same way it does everywhere else in the app. Milestone progress updates stay on the milestone card and are separate from notes — the two are no longer tangled together.

Existing PO notes were migrated over with their original ids, timestamps, archived state, and author preserved.

You can share a read-only view of an order fulfillment with anyone, no account needed. On the fulfillment card there’s now a Share dialog that creates a public link, optionally protected by a password and an expiration date, with copy and revoke controls. Whoever has the link opens a curated view of the fulfillment at /share/<token>; the link resolves as “not available” if it’s been revoked, expired, or has the wrong password.

Supply shipments can now be routed to a specific location inside the destination warehouse, on both create and edit, from the shipment dialog and the Route & Destination card. The location picker filters to the selected warehouse, and receiving drops the inventory into that location on arrival. Leave it blank and the shipment keeps behaving the way it always has, routing to the warehouse’s default location. Custom destinations that aren’t a warehouse still work the same.

Shipment tracking for Walmart orders is reaching Walmart again on fulfill. When Walmart orders moved to the V2 fulfillment path, the per-fulfillment shipment-info push wasn’t wired up on the Walmart integration — the way Amazon, Shopify, Rithum, and Faire were — so tracking silently stopped syncing on fulfill. The manual Push Shipment Information button was unaffected. The per-fulfillment push is now in place for Walmart alongside the others.

Import notifications in the inbox no longer truncate their body text, so the reason and any per-row detail is visible without having to open the source. The title stays intact, and a collapsed raw metadata panel sits underneath the download attachment for anyone who wants to look at exactly what was posted.

Product cost by quantity was treating a tier’s quantity as an upper bound; it’s actually the minimum quantity that unlocks the tier. A 100-unit PO against a ≥ 50 → $X tier was reading the wrong cost. It now matches the price side: the highest tier whose minimum is met wins, ordering zero returns the base cost, and same-day tiers apply immediately instead of waiting until midnight.

The Recent Orders tab on an inventory or product detail page now filters by the linked product instead of the order’s brand, so orders that don’t carry a brand are no longer missing from the list. Orders you’d expect to see against a SKU show up whether they came in through a branded channel or not.

Bulk inventory pushes to Shopify now use the integration’s configured inventory destination warehouses when calculating what to send, instead of relying on a warehouse row existing for that SKU. Products that had no location row for a destination warehouse were dropping out of the future-inventory number Shopify saw; those SKUs now push a correct value on the same cadence as everything else.

Sales order numbers could duplicate when an older order held a higher sequence than the most recently created one. The next-number lookup used the newest order by created-at; it now uses the maximum sequence across all matching orders, archived ones included — the same approach purchase orders already use.

Clicking an invitation link a second time — after it’s already been accepted — now returns a message that says what to do: log in with your email and password, or use “Forgot password?” on the log-in page to reset it. Before, the response was a generic “token is not longer valid” error that gave no next step, and it was recorded as a system error even though re-clicking a used link is ordinary user behavior. The message and the response type are now correct for what actually happened.

Accepting an invitation checks the new password’s length against the configured minimum. The check was in place but wired to a setting key that didn’t exist, so it silently passed on anything. New passwords set through an invitation now have to meet the minimum length, matching what the sign-up form was already asking for.

Purchase-order status is now the single source of truth for where a PO sits in its lifecycle — draft, issued, in production, in transit, delivered, closed, canceled. The active milestone is derived from that status rather than something you move separately: boundary statuses (Draft, Closed, Canceled) simply have no active milestone.

Milestone progress is now its own layer. You can update a milestone’s progress percentage, timeline status, dates, and notes without also moving the PO to a different lifecycle status — the two used to fight each other, and now they don’t. Auto-populating milestone dates now happens in a single update from the PO detail page.

On the PO detail page: the duplicate status-change path that lived in the status dropdown has been removed, and the milestone controls line up cleanly.

Veracore is now connected on the shipment path in both directions. Orders sent to Veracore for fulfillment can be shipped from Veracore and Endless picks up the shipment, and the Ship Order flow records the Veracore shipping-order id as the external reference so later polls line up. Extra carrier mappings were added alongside so more of Veracore’s carrier codes resolve to the built-in list without a manual mapping.

You can now duplicate any sales order — from the order’s Actions menu, pick Duplicate Order and a new draft is created from the source, however the source order was created. The duplicate copies items, quantities, prices, discounts, tags, notes, gift message, ship-to and bill-to addresses, carrier and routing selection, B2B data, and shipping and tax. It does not copy identifiers, status, or fulfillments — the source order stays exactly as it was, and the duplicate has no history of its own.

You can pick a new order number or leave it blank. If you leave it blank the number is derived from the source — ORD-1 becomes ORD-1-01, ORD-1-02, and so on — which keeps duplicates identifiable and unique within a sales channel. The dialog also gives the option to open the new draft in quick view right away. Bulk duplication is available over the API today; a bulk action in the UI will follow.

Customer instructions are now called instructions everywhere. The order detail reads and writes through the new field, and fulfillment instructions behave the same way gift messages now do — a fulfillment’s instructions override the order’s if set, otherwise the order’s instructions apply. Packing notes sent to ShipHero and Packiyo use whichever value resolves.

The older note name is kept as a compatibility alias for anyone reading or writing through it, so nothing breaks — but new integrations should reach for instructions.

An order can no longer end up carrying a sales channel from another company. A channel belonging to a different company was showing up on some orders, and the cause was two write paths letting a wrong-company channel slip through: order create/update was keeping per-request state on shared instances that leaked between concurrent requests, and the sales-channel automation action never checked the channel’s owner. Both paths now scope the channel to the order’s company and reject a channel from anywhere else. Already-affected orders will be corrected in a separate cleanup.

Manually importing an older Shopify order used to look like nothing happened — no order, no error, no note anywhere. The failure was always there: Shopify blocks import of orders older than 60 days without an extra permission grant, and that failure was getting silently dropped instead of shown.

Failed imports now log a clear line against the Shopify integration explaining what happened — whether the order couldn’t be found, the connection needs to be reconnected, or it’s a temporary issue that will retry on its own. Actually pulling in orders older than 60 days still needs a permission change on our end — that’s a separate follow-up.

Suppliers now carry an optional handle — a URL-friendly identifier, unique per company where set. You can set it when creating a supplier (the create dialog suggests a kebab-cased handle from the name and lets you override it) and edit it later from the supplier detail page’s Actions menu. Two suppliers in different companies can still share the same handle, and the field is validated to lowercase letters, numbers, and hyphens up to 50 characters. The suppliers list has a Handle column (hidden by default, toggleable from column settings), and the supplier detail page shows the handle inline in the header. Uniqueness is enforced by a partial unique index (company_id, handle where handle is present).

Amazon FBA orders now record each order line’s unit price instead of unit-times-quantity. Before, a two-unit line at $10 landed as $20 per unit — so multi-unit FBA lines came in with inflated per-unit prices, which then flowed through to reporting and downstream systems. The mapper is corrected going forward, and an FBA-only backfill rake task walks existing Amazon FBA orders and rewrites the affected line prices to the right value. Non-FBA Amazon orders were not affected and are left alone.

Fulfillment-owned details — the shipping address, carrier and service, notes, B2B info, external ID, and decompose / recompose — can now be edited without first claiming authority over the sales order. These edits were always allowed; the app was gating them behind the same authority as order-structure changes. Order structure itself still needs authority; only the fulfillment-scoped fields opened up.

A fulfillment’s gift message now falls back to the order’s gift message whenever the fulfillment doesn’t have one of its own. Setting a gift message on the fulfillment still overrides the order, same as before. Outbound payloads to ShipStation, ShipHero, Packiyo, MasonHub, and Infoplus use whatever the fulfillment resolves to — so a gift message set once on the order shows up on the shipping label without having to be re-entered on every fulfillment split from it.

Kingsgate Logistics LTL Freight 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 — no SCAC or tracking URL is prefilled, so those stay editable per shipment.

Multiple internal sales channels can now map to a single external store on the same integration — for example, Faire USA and Faire Canada both pointing at one “Faire” store in ShipStation. Warehouse mappings work the same way (two internal buildings, one ShipStation ship-from address). Before, the mapping refused to save with an “already mapped” error, because a defensive uniqueness rule assumed one internal per external per integration.

The mapping modals have been inverted to match. The internal value is now the row, and the external ShipStation option is the dropdown — the reverse of the old layout. That’s the shape you need to have many internals pointing at one external, since whichever side owns the rows is the side you can repeat. Each internal channel or building can still only claim one external key, so mistakes like the same building mapping twice are still caught.

Automations can now run the moment an order gets approved — the transition from draft or pending into ordered. Pick Order Approved as the trigger, and conditions and actions that only make sense after approval — checking the sales channel, applying a routing strategy — are available from the same picker. Approvals coming in through less common paths still route to the right company automatically.

Orders now log an “Order created” entry on their activity timeline, with the name of the person who created it, the moment they’re created — whether they come in as draft, pending, or ordered. Before, the timeline was blank until the first later action, so there was no record of who created an order or when. Existing orders without a create entry stay as they are; new ones from here on carry the line.

Each product now has a place to record how outside systems identify it — Amazon’s ASIN, Whole Foods’ UPC, Target’s TCIN, and so on — kept in one registry per product rather than scattered across integration configs. On the Relationships tab of a product, a new grid lets you add, edit, and remove these identifiers, with a Linked / Unlinked badge so you can see at a glance whether an identifier is already attached to a specific connected integration or is sitting in the registry waiting to be linked. Adding one pulls the partner name straight from the connected integration you pick, previewing exactly how it will be stored once linked, and duplicate entries surface a clear message instead of a silent failure.

From the integration side, a new Link External IDs action on the integration’s Actions menu opens a bulk-link modal that attaches all of an integration’s unlinked identifiers at once by partner name. Linking runs as a background job, so a big backfill returns to you immediately and completes on its own. Linked rows are click-throughs — opening the connected integration in a stacked side view without leaving the product page.

Underneath, this is a first-class registry with its own permissions and audit trail; every add, edit, remove, or link event is captured. Inbound order ingest already reads this registry to resolve products from partner-supplied identifiers — see the separate EDI 850 entry — so what you curate here directly drives how partner orders find their way to the right product.

Two lines on the same fulfillment that resolve to the same product in the same warehouse — two bundles that share a component, or a bundle plus a standalone line of that same component — now allocate together instead of stopping with a “split these items into separate fulfillments” message. The two lines are added up, allocated against the summed quantity, and split back across the lines with each keeping its own identity, and the commit that follows decrements the location once by the combined amount rather than by whichever line wrote last.

The same aggregation now runs during the availability check when you edit items on a fulfillment, so two lines of the same product whose combined increase would exceed stock are rejected together instead of each passing a check that only saw its own share.

Lead time is no longer required on a product cost. Saving a supplier cost or a purchase order cost tier without entering a lead time works — the value is stored empty rather than as a stand-in zero. If you do enter one, it still has to be a positive whole number.

Customer admins can see shipment and duties data on Shipment Financials again. After shipments moved to a company scope for multi-brand support, the financials view was still deciding access on a per-brand basis, so shipments that weren’t tied to a specific brand denied access to admins with company-wide reach — sometimes silently blanking the section, sometimes surfacing a permissions error toast. Access is now checked against the company scope, matching the underlying shipment view.

Two connected issues are fixed. Triggering a Cin7 order import while one was already running used to start another copy alongside it — repeat clicks piled up multiple concurrent imports of the same integration, each about an hour long. Cin7 imports now dedupe: a second trigger for the same integration exits immediately while the first one finishes, so re-clicking Import is safe.

That pile-up was the reason outbound shipment tracking to Rithum and DSCO had been landing hours late — the stacked imports were monopolizing the same lane the tracking pushes flow through. With the pile-up prevented, and Cin7 imports moved off that lane to join how every other integration’s import runs, tracking pushes go out promptly again.

Notifications have their own home now. The bell inside the profile drawer is gone; in its place is an Inbox entry in the sidebar with an unread count and an active-process indicator, opening a dedicated page instead of a small drawer. Filtering lines up with the notification categories the API supports, so what you see under each filter matches what’s actually there. Long-running processes still surface progress the same way — the Inbox is where you go to look through them without stacking a drawer over the app.

ShipHero shipment webhooks now match up to the correct fulfillment even when ShipHero has truncated the identifier it echoes back to us. Before, the handler only looked up fulfillments by that echoed value, so a truncated identifier meant the webhook was accepted but the shipment never got recorded — the fulfillment sat waiting despite ShipHero having sent the update. The handler now falls back to the ShipHero order id (the same one the manual “get external shipment” path already uses) when the primary lookup misses, and it tries both forms ShipHero can send that value in. Cross-integration protection is preserved: fulfillments still only resolve within their own integration.

Two problems that surfaced for tenants with more than twenty integrations are fixed. On a Shopify integration, the Manage Attribute Mappings modal — reached from Data Mapping → Product Publishing — used to open with the wrong header, no tabs, and no Fetch or Auto-Map buttons; it now opens correctly regardless of how many integrations exist. Push Product Data on a product page also now includes older Shopify integrations that were dropping off the list. Both surfaces were reading from the same integrations lookup, which was silently returning only the most recent twenty. Shopify targets that have product push turned off in their settings now show as grayed-out in the picker instead of being missing entirely.

Settings and Help have moved off the sidebar and into the company menu in the top-left, which frees up room for the primary navigation. A reusable dismissible announcement bar is in place at the top of the app for one-off notices, and the sidebar itself is tightened up so more of the navigation fits without collapsing groups.

Outbound EDI 810 invoices to Whole Foods (and, by the same path, 855 acceptances, 856 ASNs, and 846 inventory updates) were failing whenever a template referenced a per-integration location code mapping to resolve a city or address. The lookup had been available to inbound 850 templates but not to any outbound document, so the mapping came through empty and every location field on the document blew up.

The same mapping is now available to every outbound EDI template through the single point every outbound render already goes through, so this class of failure can’t resurface on another document type. If a given integration’s location mapping is empty, that’s still a setup issue rather than a bug — reach out and we’ll help populate it.

Forwarding shipments is now a bulk action. Select a set of shipments on the shipments list and forward them all in one go instead of opening each one individually. The bulk path runs the same forwarding logic per shipment as the single-shipment action, so any per-shipment failure is reported without holding up the rest.

A broad round of improvements across the EDI order path — from how orders come in, to how they’re matched against your catalog, to how outbound documents go out.

Inbound matching and units. Inbound EDI orders now match products through the same partner-identifier registry you maintain on the product page — UPC, ASIN, TCIN, whatever the partner sends — and convert cases or inner packs to eaches automatically, using a per-partner unit-of-measure mapping so quantity and price land correctly. Those mappings now live on the integration’s Data mapping tab, so you can add, edit, and remove them yourself instead of asking engineering to. A line that can’t be matched or converted doesn’t fail the whole order — it’s flagged and held so you can finish the mapping and let it through.

Inbound carrier mapping. Incoming orders resolve their requested carrier through the same custom and global carrier mappings other integrations use, so per-brand and global mappings you’ve set up for a partner’s carrier codes are applied on the way in. When no mapping matches, the raw external value is kept on the order so it can be resolved on the fulfillment.

Inbound B2B data. Orders created from an inbound document now carry their B2B data — label and routing flags — straight onto the order.

Outbound documents. Acknowledgments, ship notices, and invoices are flowing reliably again. Acknowledgments carry the right PO references, a class of documents that used to render empty on certain orders now renders correctly, and ship notices and invoices that had silently stopped going out after an internal migration are going out again — each ship notice tied to its specific shipment, and the invoice sent once, when the order finishes shipping. The per-partner configuration you already have still controls which documents are sent, and a document that fails to send now surfaces instead of failing silently.

Forward Shipment now works on EDI orders, and moved to the per-fulfillment action menu — click it and the same Advance Ship Notice dialog opens for review before sending. For every other integration the button behaves as before.

Behind the scenes, order shipments are backstopped so a near-simultaneous webhook can’t create a duplicate, the admin bulk-deliver task sends acknowledgments alongside ship notices and invoices, and the internal tool used to author and validate a trading partner’s template got a faithful live preview plus a dry run that shows exactly how an order would resolve, without touching a real order.

Inventory sync is no longer all-SKUs-or-no-SKUs on a channel. The Inventory list has a Sync tab with one column per connected sales channel, showing whether each SKU is syncing and the quantity that would push. Select rows and use Bulk Actions → Disable / Enable Inventory Sync to mark a SKU out of stock on one channel without touching its inventory anywhere else, or open an item’s quickview and toggle individual channels from the Channel Sync card.

When a SKU is opted out on a channel, Endless pushes a quantity of zero on that channel; every other channel keeps pushing the real on-hand. The same SKU can be out of stock on one channel and live on another. Opt-outs take effect on each channel’s next scheduled push, on Shopify, Rithum, Walmart, Amazon FBM, Faire, Sellbrite, Skubana, and Orderful.

The item detail page’s Syndication card also picked up a header control that acts across every connected integration at once. A status badge reads Active, Out of Stock, or Mixed at a glance, and one button flips every channel to active or every channel to out of stock in a single call instead of toggling each row on its own. Per-integration quantities on the same card now read with thousands separators — 1,234 instead of 1234.

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.

Unit cost fields on purchase order lines and shipment product costs now show and save their full supported precision — up to four decimal places — instead of being silently capped at two. The edit box starts at two decimals and expands only when a value actually has more precision, so 10.12 still reads as 10.12 and 10.123 reads as 10.123. The read-only Unit Cost column picks one precision per column — the most precise item in the column, up to four — so every row stays aligned without hiding any item’s precision. Extended cost and total columns still show at two decimals.

When an order arrives with a carrier service Endless doesn’t recognize, the Resolve carrier service dialog on the fulfillment now offers a checkbox: Map to for future orders. Tick it and the chosen mapping is saved as a custom carrier mapping for that integration, so the next order with the same external carrier name resolves on its own. Leaving the checkbox unchecked applies the carrier to just this fulfillment, same as before. The dialog also skips offering the checkbox if a mapping already exists for that external name. The Resolve shipping address dialog now reuses the same form as the regular Shipping Info editor, so the entry surface is one consistent surface instead of two.

Orders that land without a routing automation used to leave you creating fulfillments one order at a time. Sales Orders now has a Create Fulfillments bulk action: select up to 50 orders, choose a routing strategy, and Endless creates the fulfillments by running that strategy across them. Orders that already have fulfillments are skipped so nothing gets over-fulfilled, and the running progress and skip summary land in the notifications toast and panel.

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 unit of measure dropdown on the product page picked up a lot of new options. Weight now has Gram, Kilogram, Ounce, and Pound alongside the existing entries. Volume gains Fluid Ounce, Milliliter, Liter, and Gallon. Length and area cover Millimeter, Centimeter, Meter, Inch, Foot, Square Foot, and Square Meter. Container and grouping units — Bale, Bundle, Drum, Jar, Pair, Pallet, Roll, Sheet, Tin, Tray, and Tub — round out the list.

The Settings sidebar has a new Resources group with two links — Docs and API — that open the public documentation in a new tab. One less reason to leave the app to find them.

When you manually trigger Get External Shipment on a ShipStation fulfillment and ShipStation reports that the shipment hasn’t shipped yet, that result now lands as an activity log entry on the order — so it’s clear from the timeline that the fetch ran and what came back. The nightly background check keeps suppressing the same log entry to avoid noise; only the user-triggered case posts.

EDI now shows up across the app instead of only on the EndlessEDI integration tile. The Orders, Channels, and Integrations empty states each include a Connect over EDI option, the Dashboard carries a small EDI card, and the sidebar footer has an EDI button. Each opens a Talk to us about EDI modal with a booking link, the EDI guide, and an email fallback.

The Integrations page also picks up a richer EDI-ready tray, opened from its empty state. The tray shows your account’s ISA ID, the qualifier, and the supported communication channels, and includes a drafted retailer-outreach email you can preview and copy when you’re starting EDI with a new partner.

Orderbot is a new way to capture sales orders that come in over email. Every company has a forwarding address ending in @orders.endlesscommerce.com — visible at Settings → Orderbot, on the Sales Orders ⋯ menu, and as a secondary action on the empty Sales Orders state. Forward an order email to that address and Endless turns it into a draft sales order. The primary Add order button is unchanged.

Automations have a new Assign Fallback Fulfillment Carrier Service action. It sets a carrier on a fulfillment that doesn’t have one yet, leaving any fulfillment that already has one untouched. Run it before Assign Fulfillment Profile in the same automation and a fulfillment that arrived without a carrier picks up the fallback first and then auto-processes, instead of stalling because no carrier was set.

Useful when a sales channel — particularly a custom one — doesn’t carry a carrier through on the order, and the same fallback applies regardless of which fulfillment profile ends up running.

When a fulfillment-processing rule that combined several clauses — warehouse plus payment status, for example — failed, the order’s status was listing every clause the rule had checked, including the ones that actually matched, as a blocker. That made it look like the matched warehouse was holding the order when the real blocker was elsewhere. The label now calls out only the clauses that aren’t satisfied, so the reason an order isn’t moving is the reason listed.

Orders V2 — the new order and fulfillment system that most accounts are now running on while it works its way to general availability — picked up a wide round of improvements this week. None of these are large on their own; together they’re the shape of the system getting closer to GA.

Order data. Notes are now real fields on orders and fulfillments instead of being tucked into ad‑hoc data, and Shopify customer notes sync straight into the order note. B2B information lives in its own stable place on both the order and the fulfillment — so reports and integrations can read it without poking around — and the third‑party billing card is gone, with its fields rolled into B2B Info. The order timeline now reads from the system log and labels every event as System, Human, or coming from a connected integration.

Editing in‑flight orders. Item edits used to be blocked outside of draft. They’re now allowed in any non‑cancelled state, and lines that aren’t tied to an active fulfillment can be edited even when the order is in progress or already fulfilled — so a correction on a live order doesn’t require walking it backwards. Items that came in marked Not in catalog can be re‑matched by SKU, linked to an existing product, or turned into a new catalog product on the spot. Pending orders with an unrecognized SKU no longer get blocked from acceptance.

Fulfillment. The Refresh Order button works on V2. Fulfillment profiles can be assigned even on in‑progress fulfillments, and the Create button shows up when none exist. The Mark Fulfilled action stays visible (enabled only when the fulfillment can actually be marked or is running through a profile). The fulfillment integration button now points at the right system. The availability panel reads from an order‑scoped source so it loads on large orders. Cancelled orders no longer show an empty Items to Fulfill section. The metadata tab is cleaner, with external ID editable inline. Endless Window fulfillment profiles got a coverage follow‑up. Sales order details auto‑expand the sections that have content.

Shopify on V2. Several Shopify edge cases stopped surprising people: fulfillment state no longer slides backwards, cancellations propagate to Endless, digital order lines and fulfilled counts line up correctly, and near‑simultaneous webhooks can no longer duplicate a shipment. Cleanup tasks are bundled in for orders the bugs already touched.

We’ll start logging V2 changes individually once the beta closes; while it’s still in flux this often, grouping reads better than enumerating.

The Push Product Data action is reachable from the products list as a Bulk Actions → Push Product Data, alongside the existing entry on a product’s detail menu, and can now target Shopify as well as ShipHero. The dialog has an integration selector with a per-integration settings recap — Shopify shows the attribute mappings, ShipHero shows kit type and the rest — and pre-fills the toggle settings from each integration’s configured defaults. Settings categories with nothing visible are hidden, so the dialog stays focused on what matters for the chosen channel.

A fulfillment can now carry an assigned supplier. The fulfillment detail page has a new Supplier card to assign, change, or remove the supplier; fulfillments with a supplier present show a Dropship badge, and the fulfillment orders list gains supplier and Dropship columns and filters. The underlying record stays neutral — it’s an association to a supplier — so the same data can later be reported on by supplier without a redesign; the Dropship treatment lives in the UI.

Product details can now be pushed from Endless into ShipHero. Run the new Push Products action and Endless looks each SKU up in ShipHero, then creates or updates the product with name, SKU, barcode, dimensions, country of manufacture, tariff code, customs description, value, and customs value. Bundles reconcile their kit components in the same pass. Inventory is never touched by the push — only the product record.

The ShipHero settings tile also got a small tidy: the kit-type choice (Virtual or Pre-Built) is now explicit, the wholesale and 3PL copy reads more clearly, and a few settings that were never wired to anything have been hidden.

The ShipStation sales-channel mapper no longer asks operators to paste in a raw store ID. On a ShipStation integration’s Data tab, Add Mapping is now Manage Mappings, which opens a modal that fetches your stores live from ShipStation and shows each as Store ID, Store Name, and the sales channel it’s mapped to. Existing mappings appear at the top, read-only; unmapped stores appear below with a sales-channel picker. Re-fetching the list never duplicates a store you’ve already mapped.

The store name is saved alongside the mapping, so reports and detail pages can show the human-readable name. The free-text edit pencil has been retired for ShipStation rows — to change a mapping, delete it and re-map through the modal, so the store ID and name can’t drift apart.

This is what last week’s channel-listing work was for. Any other integration that exposes a list-channels capability gets the same shape automatically.

Brands are how multi-brand companies organize their product data inside one Endless account — each brand has its own catalog, settings, and team, while sharing the same company. A bug had been blocking company admins from adding new brands: creating a brand appeared to succeed but the new brand never showed up in the brand list, leaving the admin with no way to manage it. That’s fixed — a brand created by a company admin now appears in the list right away, the same as it always has for super-admins.

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.

Creating a product no longer creates an empty inventory row at every warehouse location. Missing rows are treated as zero everywhere, and a row is created on demand the first time real stock or an allocation lands at a location. This removes a long-standing tax on product creation and brand setup, and clears the way for faster Inventory, Products, and Buildings pages by getting rid of millions of empty rows that were never operationally meaningful.

The filtered Inventory page — when narrowed to a specific building or location — now lists only items that actually have a row at that location. The unfiltered Inventory page is unchanged: it still lists every item, with zero where nothing is on hand.

Packiyo is now a connected fulfillment integration. Set up the connection from the integrations settings — the new Packiyo tile takes a per-brand bearer token and a tenant URL — and once it’s saved, Endless pushes allocated fulfillments to Packiyo as orders and records shipment and tracking back automatically: by webhook in normal operation, with a scheduled backstop that picks up anything the webhook missed.

This is the first phase of the Packiyo integration; it covers authentication, ship-order push, and shipment sync.

The purchase order details card now shows and edits Expected Complete Date — the date you expect the PO to be fully complete — wired to the existing field that the CSV importer already populates. The purchase orders list and the export also gain the matching date-range filter for Expected Complete Date, so reports can be sliced by it the same way as the other PO date fields.

This consolidates around the existing Expected Complete Date instead of the briefly-shipped Ready Date field; per product direction, Ready Date is no longer surfaced in the UI.

Sales channels now carry an optional handle — a short, stable identifier that travels with the channel even if the display name changes. You can set a handle when creating a channel, and edit it on the channel header card; it auto-suggests a kebab-case version of the channel name and you can override it. Handles are lowercased, validated against the allowed shape, and must be unique inside your company; the same handle can be reused across companies.

Suppliers can now be imported into Endless from a CSV, using the same import flow as products and orders. The entry point lives on the Suppliers page — including its empty state — so the first set of suppliers can be brought in without entering each one by hand.

International orders headed to countries that don’t use a state or province — Taiwan, for example — were failing fulfillment address verification on the missing state field and stalling. Verification now accepts international addresses without a state, so those orders keep flowing through fulfillment.

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.

Purolator is now selectable as a system carrier alongside the other system carriers, so brands shipping with Purolator can pick it on shipping methods and fulfillments without a custom carrier setup.

The attributes list opens to the tag view now instead of the table view. The tag view is denser and more visual, and the table view is still one click away in the display options.

Creating and editing an automation now happens in a real builder instead of a name-and-trigger dialog. New automations open in a quickview that walks you through When (the trigger), If (conditions), and Then (actions); a toggle takes the same editor full page when you want more room. Editing an existing automation happens inline inside the Workflow card on the automation detail page — the header and tabs stay put, only the card content swaps between read and edit.

The trigger picker is searchable. Conditions group into Any/All blocks that can be nested, and each field gets a value editor appropriate to its type — chips for tag-like values, selects for fixed lists, numeric inputs for numbers, a date picker for dates, and live pickers for things like products and warehouses. Actions stack as cards with their parameters inline.

ShipHero’s packing note was reading from a legacy handling-instructions field and missing the per-fulfillment instructions added with the new notes feature. The packing note now reads a fulfillment’s instructions first, falling back to the order-level note when the fulfillment doesn’t have its own — so what an operator types into a fulfillment’s instructions actually reaches the ShipHero pickers.

Purchase orders can now make a clean round trip through CSV. Both the import tool and the export tool got a pass so you can pull POs out of Endless, edit them, and feed the file back in without losing fidelity.

On import, the PO Number is now the key. A row whose PO Number doesn’t exist creates a new PO; a row whose PO Number matches an active PO updates it; archived POs are rejected so an old one cannot be revived by accident. Line items inside a PO match on Item SKU: quantity, unit cost, and lead time update on existing lines, new SKUs add a line, and lines you didn’t reference are left alone. The header is editable too — supplier (matched against your active suppliers by name), terms, instructions, key dates, financial status, and cost allocation status — and you can submit a header-only row to update or create a PO without listing any items. Imports fail loudly when something doesn’t add up (unknown supplier, invalid date, conflicting headers, duplicate SKU in a single import). Columns the importer doesn’t recognize are skipped instead of failing the file, listed back to you in the import result.

On export, there’s a new Export dialog matching the orders and inventory flow. Exports honor the filters you have set on the Purchase Orders list, so what you see is what you get, and you can pick between an import-ready export — round-trippable through the importer — and a complete export that includes every field on the PO.

Behind these two flows, the PO Number is now a real natural key: a simple format (letters, numbers, _, -, .) and unique within a company across active and archived POs. Duplicates can’t be created, imported, or generated.

High-volume ShipHero accounts could see recent shipments never land back in Endless. The every-fifteen-minute reconciliation was paging through ShipHero’s oldest-first recent-shipments feed from the start on each run, which meant a busy day could exceed the pagination limit before reaching the newest fulfillments, and an upstream timeout would silently restart the scan from zero on the next pass.

The reconciliation now drives from Endless’s own backlog of in-progress fulfillments instead — anything not yet completed, within a fourteen-day window — and pulls each fulfillment’s shipment from ShipHero by order. No pagination cap, no scan-from-zero on every restart, and no silently skipped pages on a busy day.

The toolbars across list pages — products, orders, POs, shipments, suppliers, and the rest — got a pass for consistency. The big “Add Product” / “Add Order” buttons that opened a dialog are now a compact + icon, since + and the edit pencil are already the standard add/edit affordances throughout the app and the long label was taking more space than it earned. The button still sits in the primary spot; it just doesn’t shout.

Filter buttons, the “More actions” overflow, and the new add-as-+ all share a single chrome treatment so they read as one toolbar instead of three different ones. The view picker (table / cards / tags) that used to live next to the toolbar moved into the Display Options menu, matching the pattern most apps use and giving the toolbar back the row of horizontal space.

Hovering any icon-only button in those toolbars now shows a tooltip naming what it does — the + add action, the view-options slider, the more-actions overflow, the column toggle — and the same label is exposed to screen readers. The … that used to trail the add label is gone now that there’s a hover label to lean on.

Two fixes to how inventory gets pushed to Rithum.

Inventory pushed to Rithum was under-reporting for composable bundles. A bundle has no physical units of its own — it’s sellable because its components are in stock — and the number Endless sent didn’t account for that, so Rithum saw zero available on bundles that were actually sellable. Rithum now receives the same available-to-sell quantity that Endless shows in the app, including the make-from-components portion for bundles. For accounts that map more than one warehouse as a Rithum inventory destination, the global quantity is now reported against a single primary warehouse rather than split per warehouse — per-warehouse splitting is deferred. Worth a look at production mappings post-deploy if any Rithum integration has multiple warehouses configured.

Separately, the Rithum integration’s “push inventory” master switch wasn’t being honored by the scheduled bulk sync — only by the one-off push that fires when an inventory level changes. So turning the switch off would stop the live pushes but the scheduled sync kept pushing every item to Rithum anyway. Both paths now share the same guard. Turning push inventory off stops all outbound inventory updates to Rithum, scheduled and event-driven.

Two changes to how Shopify orders connect to products in your catalog.

The “Import products” action on a Shopify integration always works now. Before, the action was silently blocked on integrations whose product-import setting was off, so the only way to pull in products was to turn that setting on first. Whether to import is your call from the UI; nothing else gates it.

The same setting still exists, but it now controls a narrower behavior: whether Endless should automatically import a missing product when a Shopify order comes in referencing one. The default is off, so order ingest no longer creates products on its own unless you opt in. Integrations that already had this setting on stay opted in.

Regardless of that setting, an order item that arrived without a matching product is now linked to one as soon as the product shows up — created later, imported manually, or updated with the SKU the order is referencing — so an order that landed before its product did doesn’t stay orphaned. V2 orders behave the same way as V1.

EDI 850 orders coming in through the Orderful path could fail to import on every order when the inbound template didn’t include a shipping carrier service. Order creation was rejecting the input outright, even though the carrier service is supposed to be set later at fulfillment, not on the inbound PO.

EDI 850 orders without an inbound carrier service now import as expected. Any carrier mapping the template does send is still picked up.

ASNs to Extensiv buildings were silently failing on items that don’t have lot tracking turned on in Extensiv. Endless was attaching a lot number to every receiver line, and Extensiv was rejecting the whole receiver when the item wasn’t lot-tracked, so the ASN never landed.

There’s now a “Send lot number” setting on the Extensiv integration, off by default. Turn it on for accounts where every item is lot-tracked; leave it off otherwise and ASNs go through without a lot number attached. Integrations already configured to send a reference number as the lot number are unaffected — that setting still wins.

The orders list now keeps itself current as your team works. When a teammate moves an order — fulfills it, marks it in progress, holds, releases, allocates, edits details — the list picks up the change in the background instead of staying stale until you reload. Refreshes from your own actions don’t trigger an extra reload, so the page doesn’t flicker as you work.

A few order changes — cancel, uncancel, and unfulfill — don’t refresh the list yet; the list will start picking those up automatically once they’re being broadcast.

Archived purchase orders are now first-class on the PO list. A new filter lets you switch between active POs (the default), archived-only, or everything; archived rows can be opened and read on the detail page, with notes, events, milestones, live status, and the archived line items (each marked with an Archived badge in the items table) all available, and a clear Restore action is offered from both the list row menu and the PO details actions menu. Restoring runs through the same in-app process tracker the rest of the bulk PO actions use, so you can see when the restore lands instead of guessing from a toast.

The Archive action is also no longer hidden on POs that aren’t in a draft state — you can archive a PO at any status, which matches how teams actually use archive (clearing out a mistakenly-created or no-longer-relevant PO regardless of where it got to). Write actions on archived POs still require restoring first; only reads were opened up.

Two more Settings pages have been rebuilt into the new Settings layout.

Team & Roles replaces the old team list. Search across members, and use the All / Admins / Operators segmented filter — each with a live count — to narrow the list. The table shows name with an avatar, email, role as a badge (with a clear “No roles” state), status (Verified vs. Pending), and the date each member joined; click any row to open the existing member dialog. “Add member” opens the same invite flow as before.

Brands has been rebuilt as a standard table with debounced search, an “Add brand” action in the toolbar, skeleton and empty states, and the existing pagination footer; clicking a row opens a dedicated brand detail page where you can edit a brand’s fields in place, with a back affordance to the list. The previous card grid is gone.

Exporting a fulfillment order PDF for a bundle that has been decomposed into components now shows the component rows the warehouse actually needs to pick, the same way the on-screen decomposition table does. The parent bundle row is muted so it reads as a header, the fulfillable component rows sit on the normal row background, and the PDF totals are calculated from the components — so what’s on the PDF matches what’s on the page and what the warehouse will be packing.

If you run multiple ShipStation stores behind a single ShipStation connection, you can now route orders to the right store based on the sales channel they came in from. Map each sales channel to its ShipStation store id on the ShipStation integration, and orders from that channel will ship out of that store. Channels without a mapping continue to use the integration’s default store, so nothing changes until you start filling the mappings in.

Some products were showing Total Incoming as zero even though they had open purchase orders covering them. The PO-coverage and incoming-quantity lookups on a product were keying on a denormalized SKU that wasn’t being filled in on every inventory record — anything created outside the product-add flow (bulk inventory init, shipment receipt, fulfillment) was leaving it blank, and the lookup missed. The lookup now resolves the SKU reliably for every record, and a backfill is queued for the historical rows that were blank.

The notifications drawer could show its All tab empty while the Unread tab still listed notifications — confusing, since “All” should be a superset. The All tab now lists everything as expected, regardless of the kind or category a notification carries. As a small follow-up, the “Mark all as read” action is hidden when the list is empty so it no longer lingers over an empty state.

Archiving an order fulfillment used to leave its underlying fulfillment items live behind it. Cancels, unfulfills, and a few Shopify paths all hit this — the fulfillment looked archived, but its items kept hanging around and could show up in downstream lookups. Archiving now cascades to the items in one step, so an archived fulfillment really is fully archived. A separate backfill is queued for the historical rows that were affected.

When you have an order detail page open, the app already pops up a notification any time another teammate or an integration makes a change to that order, so what you’re looking at stays in step with what’s actually happening to the order. Those notifications now lead with the order number (“Order #1234 updated”) and call out which part of the order changed, instead of generically announcing that something was edited. If a few arrive at once, you can tell at a glance which order each one is about and where the change was.

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.

A single building can now serve more than one fulfillment integration. Instead of every fulfillment from a warehouse defaulting to that warehouse’s one integration, each fulfillment can carry its own — and playbooks can pick the right one automatically based on the rules you set up (order source, brand, customer type, anything a playbook condition can read).

In practice: one building can route some fulfillments to ShipHero, others to Extensiv, others to a 3PL — all from the same physical location, all automated. The Send / Resend button on the fulfillment card now shows the actual integration the fulfillment is going to, and downstream work — cancel, schedule, retry — follows the same routing the playbook chose, end to end.

The Sales Orders list has had a tune-up. Columns are tighter, you can reorder them, resize them, and the horizontal scroll stays put as you go. Use the new Source filter to narrow the list to one channel — Shopify, Faire, manual, and so on — without leaving the page.

The status badge is now interactive. Click it to open a details panel that surfaces what you usually want next: outstanding issues on the order, how many items are in each fulfillment, copyable tracking numbers, and on V2 orders, a callout for any items that aren’t yet assigned to a fulfillment.

The Sales Channels panel on an integration’s Data tab has been rebuilt. The mapping table now shows External ID → Internal Sales Channel side by side, with Add, Edit, and Delete buttons on each row. Adding a mapping opens a dialog where you pick the internal channel from a dropdown. Editing a mapping lets you change the external ID; to point an external ID at a different internal channel, delete the row and add it back. Shopify, Orderful, and Veracore are on the new editor today.

An external ID can now map to at most one live internal channel per integration. If automatic discovery tries to write a mapping that would collide with one you already have, it stops and tells you instead of adding a duplicate.

Auto-discovery writes and the Infoplus ship-order step are reading and writing through the new system as well. Trackstar is still on the older one for now and will follow.

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 Sales Orders list is faster. The page now opens from a cached copy and refreshes in the background, so you see your orders right away instead of waiting through a full load. Filtering, sorting, searching, and paging keep your current rows on screen while the next set loads in behind them — no more flash to an empty skeleton between actions.

Underneath, the result count loads on its own so paging doesn’t recount the whole filtered set every time, and a few extras-only columns (PO Number, Customer Reference, Vendor Number) only fetch their data when they’re actually on screen. Two crashes also got cleared out: orders whose source integration had no name were taking the whole page down, and the cold-load skeleton used to leave a gap of empty table underneath.

The Get Shipment action on a ShipHero fulfillment is back. Use it to pull the latest shipment details — tracking, status, and shipped date — from ShipHero on demand, without waiting for the next sync.

The button shows up in the fulfillment actions menu once the fulfillment is in progress with ShipHero, and it’s hidden on fulfillments where there’s nothing to fetch yet.

ShipHero was being handed the full state name on outgoing addresses (California, Texas) where it expects the two-letter abbreviation (CA, TX). Both shipping and billing addresses on B2C and B2B orders were affected. State names are now converted to the two-letter form on the way out, and addresses that already had the short form keep going through unchanged.

You can now edit details on an order — expected ship date, sales channel, B2B / PO / customs info — at any point in its life, not only while it’s in Ordered, Draft, or Error. Whether the edit is allowed comes down to who owns the order: if it’s an order you manage in Endless, you can update it; if it’s owned by an external system, the edit is still blocked the same way it always was.

Line items still lock once an order has been placed — this change is about the order-level details, not the cart. The Change Sales Channel dialog rides the same path and now opens cleanly on every order.

Actions taken by an automation now show up in the activity log as performed by the system, rather than being credited to whichever user or integration happened to set the automation off. Automations can also run against events that didn’t have a user or integration behind them in the first place — anything kicked off on a schedule or by the platform itself.

The Add Alias button for shipping carriers is no longer Shopify-only. Custom carrier mappings can now be added on every integration except QBO — including EDI (Orderful), Amazon, Walmart, Rithum, Business Central, Cin7, Sellbrite, Skubana, Extensiv, Gobolt, Trackstar, MasonHub, Infoplus, ShipHero, ShipStation, Veracore, and Faire.

The left sidebar is now organized into collapsible category groups — Catalog, Orders & Fulfillment, Inventory, Supply Chain — with Dashboard pinned on top. Admin has been folded back into the other groups: Buildings now lives under Inventory, Automations under Orders & Fulfillment.

Settings has moved off the bottom of the sidebar to the top company dropdown (or G+S). Opening it swaps the primary nav for a Settings sidebar grouped into Account, Workspace, and Operations, with a “Back to app” link at the top. G+S now goes to Settings; Supply Chain has moved to G+U.

A round of performance work on the Products and Orders list pages and the order detail page. On large accounts these pages had been creeping up to tens of seconds, and on the largest order histories the Orders list was timing out entirely and falling through to an empty state. They’re all back down to milliseconds, regardless of how many products or orders an account has.

Order detail pages also return immediately again — the activity timeline fills in once the main page is up, instead of holding the whole page back until it’s ready.

Inventory pushes to Walmart could fail without reporting an error, depending on where they were triggered from — most notably from the dashboard, the API, and the nightly background job. Pushes from those paths now go through cleanly, so Walmart inventory stays in sync regardless of what kicks the push off.

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.”

Two new columns are available on the Shipments tab of purchase orders and the main supply shipments list: Actual Arrival and Container No. Both are sortable from the column header and can be toggled from the column menu.

Book Freight is now available from the Supply Chain menu in Endless. The tool walks teams through a freight booking request, collecting the shipper, consignee, pickup and delivery locations, cargo-ready date, freight mode, shipment type, incoterm, ports, container counts, cargo details, and special instructions.

It supports ocean, air, truck/LTL, and rail bookings, with FCL and LCL handling for ocean shipments. Compliance fields cover batteries, hazardous materials, dangerous goods, and other special cargo, and the review step summarizes the request before it is submitted to the forwarder.

DSCO orders now ship out with each brand’s own carrier service names. Up until now, every brand on a DSCO connection shared the same integration-wide carrier mapping — even when a brand had its own mapping set up. Brand-level mappings now take priority, with the integration-wide mapping kicking in only when a brand doesn’t have its own.

The Tariffs tool is now available from the Supply Chain menu in Endless. It brings the HTS catalog into the app, so teams can search tariff descriptions and HTS numbers, browse chapters and headings, and look up general, special, and column-2 duty rates without leaving their workspace.

The tool also includes a duty and tariff simulator for checking an HTS code against country-of-origin rules and Chapter 99 overlays, including Section 301, Section 232, and IEEPA-related duties. Refund FAQs, claim guidance, and tariff updates are available from the same tool.

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.

Order exports now offer four formats: Orders + Items (the existing default), a compact Orders-only export, a Shipments export, and a carton-level export. The format is chosen in the Export dialog on the Orders list.

All orders are now included in every format — previously the export was missing orders from our newer order system.

Shipments from ShipHero now flow back into Endless automatically in real time, with a daily backfill catching anything missed. Endless also records the carrier service name on each shipment, so labels like “UPS Ground” appear on the order without manual entry.

This is a continuation of the ShipHero integration first announced in May.

The SKU column on the Orders list now shows an interactive hover card listing every SKU on the order, instead of the previous misleading pill that looked like a button.

Product Attributes can now be viewed as color-coded tags as an alternative to the existing data-table view. The tag view groups attributes by section, color-codes each tag by attribute type, and offers per-tag actions for display, edit, move, and archive.

A toggle on the Product Attributes page switches between the two views.

CSV product imports no longer fail when the SKU in the row already exists but is archived. Archived products are unarchived in place and updated from the import, then re-archived if the row marks them as archived.

Eligible purchase orders can now be deleted directly from the PO detail page’s Actions menu, matching the option that already existed on the PO list. Same eligibility rules apply.

The Brands list now loads in pages (search still works as before) and shows each brand’s handle on both the list and the brand detail Settings view. This change is particularly relevant for retailers who may work with hundreds of brands.

Inventory item detail pages now include a Purchase Orders tab that lists every PO containing the SKU, with PO number, supplier, status, expected date, and ordered/received quantities.

The active tab is also reflected in the URL, so a link goes straight to the right tab.

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.

CSV imports now strip leading and trailing whitespace from each cell. Rows that previously failed silently because a SKU or identifier carried a stray space now import correctly. This applies to product, inventory, composition, and purchase order imports.

The Import Components and Export Components menu items on the products list are now called Import Relationships and Export Relationships, lining up with the rest of the catalog vocabulary. Behavior is unchanged.

Rithum (formerly DSCO) is now available as a sales integration in Endless Commerce. Orders sent through the Rithum network arrive in Endless and can be fulfilled through the same workflows used for every other sales channel, with shipment information flowing back to Rithum on dispatch.

For businesses already selling through Rithum-connected retailers, this hooks that volume directly into the same inventory, order, and fulfillment tooling used for every other channel.

The supply shipment detail page now lets you record a Received Date directly from the Key Information edit form, so the actual arrival date is captured alongside the rest of the shipment metadata.

Uploading multiple shipment documents at once no longer mixes up files between storage paths. PDFs and images uploaded together now each land where they belong and are linked to the correct document.

Dashboard data now loads faster when opening the dashboard or refreshing its data.

The same data-loading work will also support future reporting features.

The legacy product status field, used to mark products as active or inactive, has been retired. Product lifecycle can now be handled by archiving a product to hide it from normal views, or by setting up a custom lifecycle attribute for catalog-specific stages.

Archived products can be viewed with the Archived filter on the products page.

ShipHero is now available as a fulfillment integration in Endless Commerce. Inventory and fulfillment data can flow between Endless and ShipHero alongside other 3PL connections like Extensiv and ShipStation.

The activity feed on inventory, products, orders, purchase orders, and shipments now supports filtering by date range. This can be used to review changes within a specific period.

The product export tool now respects the filters active on the product list. The export contains the filtered product set, and a count is shown before the file is generated.

Every product filter is supported, including the option to include archived products. This matches the filtered export pattern already available on orders.

Custom fulfillment integrations are now supported in Endless Commerce. Developers can build a custom fulfillment app, and any team running Endless can mark that app as responsible for inventory or fulfillment on a per-building basis.

This supports 3PLs and fulfillment services that do not run on an off-the-shelf warehouse management system like Extensiv or ShipStation but still want to integrate over API.

Custom sales integrations are now a built-in option in Endless Commerce. A custom integration can be created in the app, and its API key can be shared with a developer building a sales channel. The keys use scoped permissions for sales-channel operations, including getting inventory, creating orders, and related actions.

Custom sales integrations also use the order authority system, so Endless can track which app created an order and whether that app can continue editing it.

Shopify integrations can now push Future Available To Sell numbers — inventory that is on the way to a specific building but has not arrived yet — instead of only the inventory that is currently on hand. When a shopper places an order against that future inventory, Endless Commerce can hold the order until stock physically lands, then release it for fulfillment.

Product attributes can now be pinned to the Key Info tab on the product detail page. Unpinned attributes remain available on the Attributes tab.

Products can now be archived. Archived products are hidden from the product list and from search across the app.

To view or restore archived products, apply the Archived filter on the products page.

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.

For buildings managed in Extensiv, the Create ASN action can now send a custom reference number that maps to the Lot # field in Extensiv. The same value can also be sent as the Receipt Advice Number on Extensiv receipts.

Both options are configured in the Extensiv integration settings.

All record types in Endless Commerce are now scoped to the company rather than to an individual brand. Products from different brands can share the same building, a single purchase order can cover multiple brands, and one inbound shipment can carry goods for several brands at once.

The Brands menu has moved under Catalog in the sidebar. More brand-level features are planned for brand-specific assets and settings.

Canada Post is now part of the system-defined carrier services in Endless Commerce, with both regular and expedited options available. Canada Post can be selected directly when assigning a shipping service to an order, without custom carrier setup.

Integrations are now grouped by business function in the integrations list. Sales includes channels like Shopify and Walmart, Fulfillment includes warehouse and shipping systems like ShipStation and Extensiv, and Accounting includes finance tools.

The groups make it easier to find integrations by the work they support.

Walmart is now available as an upstream integration in Endless Commerce. Like other upstream channels, it can send inventory updates out to Walmart and bring sales orders back in to be fulfilled through the rest of the Endless toolset.

For businesses already selling on Walmart or planning to start, this connects that channel directly into the same inventory, order, and fulfillment workflows used for every other sales channel.

Shopify inventory settings have a new home. When sending inventory to Shopify, everything is now controlled from the building detail page — the place in Endless Commerce where a physical warehouse or fulfillment location is configured. From there, the inventory source for a building is defined, along with which connected buildings in other systems should receive that inventory.

Putting these controls next to the building they belong to makes it easier to keep Shopify and Endless in sync without hunting through separate settings screens.

Search now works like this: the default experience looks at the key identifiers of an order or product, so common lookups return results right away. When a broader search across all product or order data is needed, the deeper search is still available as a secondary tool on the same screen.

Most of the time, finding the right order or product should feel instant. For the times when a wider net is needed, the option is one click away.

Related product attributes can now be grouped together, which makes product data a lot easier to scan and update. To set a group, open an attribute definition and fill in the Group field. The full list of groups in your account is simply the combination of every group name that has been typed in, so no separate setup is needed.

If “Taxonomy” and “taxonomy” end up side by side, the fix is quick: open each attribute definition and standardize the spelling. That fits the broader Endless approach of keeping data fixable where it lives, rather than generating meta work to clean it up somewhere else.

Endless Commerce now includes three clearer inventory definitions that show up across the app. Available To Sell is the total amount of inventory that can still be sold after every received order has been fulfilled. Available To Allocate is what remains free to assign to fulfillment orders. Total Incoming covers everything on the way in, including inventory on a purchase order that has shipped, inventory on a purchase order that has not shipped yet, and any other incoming stock.

Shared definitions like these make it easier for operations, sales, and support to look at the same screen and reach the same conclusion.

For businesses running multiple active buildings — the physical warehouses or fulfillment locations set up in Endless Commerce — incoming inventory can now be viewed on a per-building basis. Open any product’s inventory detail page and head to the location tab to see exactly what is on its way to each site.

This makes it a lot easier to plan receiving, spot gaps before they become stockouts, and coordinate across locations without piecing the picture together by hand.

Guest users are now a built-in part of Endless Commerce. Add them to a team to give anyone read-only access to the data in your account — a useful option for advisors, partners, or anyone who needs to look but not touch. Guest users can view everything except the list of other team members, keeping internal team details private.

More detailed inventory tools are now available across Endless, giving a fuller picture of stock wherever decisions get made. The inventory page has also been updated with clearer, simpler inventory definitions right alongside the numbers, so everyone on the team can look at the same screen and mean the same thing when they say “available to allocate” or “incoming.”

Better visibility plus shared language makes inventory easier to reason about, especially as operations grow more complex.

Adding a handful of new products no longer requires a bulk spreadsheet import. Multiple products can now be created at the same time directly in Endless, starting with just the essentials like product name and SKU.

This fits the broader Endless approach to catalog building: start simple, then enrich each product incrementally rather than trying to get everything perfect in one giant import. For small batches, it is a much faster way to get items into the system and keep moving.

When a new building or storage location is added to Endless, there may be no existing inventory record for certain SKUs at that location. Previously, this absence of data could create ambiguity in stock calculations. Now, Endless treats any missing record as zero units.

This makes it easier to set up new fulfillment locations without worrying about gaps in inventory data causing unexpected behavior elsewhere in the system.

A CSV import for bulk inventory updates now only needs three columns: SKU, building ID, and stock level. Endless will automatically apply those counts to the default available location for each item if no location ID is provided.

This is particularly useful when a direct API connection to a warehouse or building isn’t available, or when the building only uses default storage locations rather than a more granular location structure. Updated documentation covering this workflow is now live in our help docs.

Certifications, contracts, bank details, and other supplier-related files can now be uploaded directly to a supplier’s record in Endless Commerce. Each document lives alongside the supplier it belongs to, making it easier to stay organized as your vendor relationships grow.

All identifiers across the system such as SKUs and order numbers are now capped at 40 characters. This keeps the visual experience stable and consistent throughout the app, avoiding display issues that can occur with unexpectedly long values.

Purchase orders now support file attachments. Any documents relevant to a PO — contracts, supplier confirmations, packing specs, or anything else — can be stored directly alongside the order, keeping all related information in one place.

The Endless API documentation at docs.endlesscommerce.com is now organized by category, including areas like orders, inventory, and shipments. A new getting started guide has also been added for teams connecting to the API for the first time.

The updated structure makes it easier for developers and operators to understand how Endless data is organized and where to find the endpoints they need.

When a shipment contains line items that weren’t originally linked to a purchase order, it’s now possible to make that association directly — no need to remove and re-add the line item to get things connected.

Keeping shipment line items properly tied to purchase orders is important for accurate incoming inventory tracking. This change makes it easier to clean up or correct associations when shipments are created without the full context upfront.

The Extensiv integration is now available to all Endless Commerce merchants. Extensiv is a warehouse and fulfillment management platform used by many third-party logistics providers (3PLs), and this integration allows inventory and fulfillment data to flow between the two systems.

New configuration options have been added, including control over where ASNs (Advance Shipping Notices) are created when exporting to Extensiv. If your fulfillment operation runs through Extensiv, this integration is ready to connect.

Purchase orders can now be created from CSV files. Each row can include a purchase order number, SKU, lead time, unit cost, and quantity, making it much faster to load line items for larger purchase orders.

After import, teams can open the purchase order in Endless to add supplier notes, milestones, and shipment associations.

You can now assign a guest role to users to give them read only access to your data. This is a good fit for stakeholders, auditors, or external collaborators who need to view data without making changes.

The order export tool now respects whatever filters are currently active on the orders list. Apply filters by date, product, status, or any other criteria, and the resulting export will contain only the matching orders — no more exporting everything and trimming it down afterward.

Object headers now include a consolidated copy menu with actions for copying the Endless ID or raw JSON for the current record. The actions work across objects like orders, products, shipments, and purchase orders.

Copying IDs makes it easier to reference records in support, API, and internal workflows. Copying raw JSON gives developers, AI tools, and integration builders the full underlying data for debugging or mapping work.

The product filter on the orders list page now accepts multiple products at once. Previously limited to a single product, the filter now lets you select several SKUs or products in one go — handy for pulling up a broader slice of orders without multiple separate searches.

Shipments and purchase orders are now connected at the line item level rather than at the shipment level as a whole. This change unlocks more flexibility in how shipments are managed: line items from different purchase orders can now be added to the same shipment, and each purchase order now shows a clear breakdown of shipment progress per line item.

This is a meaningful structural improvement for teams managing complex supply chains — particularly those splitting orders across multiple shipments or sourcing from several suppliers in one delivery.

The orders page now includes a product filter. This makes it possible to search for all orders that contain a specific product.

Shipment receiving has been redesigned with a simple inline interface. Items can be received at any point during a shipment’s lifecycle — the shipment no longer needs to be marked as “In Receiving” first. Partial receiving, undoing received items, and quick full-shipment receiving are all supported. A confirmation dialog shows exactly what will change in the system before any receiving actions are committed.

A new unified product image management tool is now available. It supports drag-and-drop, bulk uploads, and reordering. The tool is accessible from the files tab on the product details page, from the product sheet view, and by clicking the featured image on the product details page.

Background jobs such as data exports are now fully functional in the sandbox environment. This makes it possible to test data flows in the sandbox before running them in production.

Dashboard cards are now interactive. Revenue and Total Orders link to the orders page with the appropriate date filters applied. Oversold SKUs and Low Stock Alerts link to the inventory table with relevant filters. The dashboard also includes subtle design refinements.

Several features are no longer tied to individual brands and instead operate at the company level. This includes Buildings, Automations, Product Attributes, and Exports. As a result, a single building can now store inventory for products from multiple brands. Products, Orders, Integrations, Purchase Orders, and Shipments will follow the same pattern over the coming weeks.

The At Destination shipment status has been removed from the shipment state flow. This status was too similar to Delivered, and removing it simplifies the process of moving a shipment through its lifecycle.

The reload order tool — used to refresh data for orders created by the Shopify integration — now supports pulling in updated order tags from Shopify.

Buildings — the locations used to manage inventory and fulfillment — can now be archived. This is helpful for staying organized, especially when cleaning up buildings that were accidentally imported from other systems. If a building can’t be archived, a clear list of reasons will explain what’s preventing it.

Order processing now supports bulk actions for up to 50 orders at a time. Select the orders you need to move forward and apply actions in one go — a significant time saver for teams handling high order volumes.

A refresh button is now available on the inventory list page to manually trigger an inventory count update. Running a refresh pulls counts from any connected systems, recalculates allocated and ordered quantities, and initializes inventory for all locations and products. It’s a quick way to make sure everything is in sync.

Companies that operate multiple brands can now define a single building in the system and use it to manage inventory and fulfillment across all of their brands. This eliminates the need to duplicate building records and keeps everything centralized for multi-brand operations.

Automations just got more powerful for order management. It’s now possible to configure automations that update specific order fields — including expected ship date and financial status — based on predefined automation definitions. This makes it easier to keep orders moving without manual updates at every step.

Purchase orders now have three new date fields: issue date, confirmed date, and closed date. These can be recorded directly on the purchase order to track its lifecycle from issuance through supplier confirmation to closure. This is especially useful for teams that don’t use the optional milestones feature but still want a clear view of where a PO stands.

When shipments are chained together to track different legs of a journey, or when a single shipment is split into multiple parts, that relationship is now clearly visible in the shipments table. This makes it easier to follow the full path of goods through the supply chain at a glance.

Tables throughout the app now have a unified toolbar at the top. The toolbar includes a variety of actions depending on the type of data being viewed, making it faster to find the right tools without leaving the page.

How inventory is managed for each building is now controlled by a single, explicit field: Inventory Source. This field drives all inventory-related behavior in the system, making it clearer how each building’s inventory is sourced and managed.

All inbound shipments — whether intermediate (factory to port) or final (factory to warehouse) — are now simply called Shipments. A shipment can have any origin and destination. When the destination is a building in Endless Commerce, incoming inventory numbers update automatically throughout the app. For buildings managed within the platform, receiving tools are available to check items directly into inventory. For buildings managed by another system, shipments can be sent as an ASN.

Shipments and Advanced Shipping Notices are now available for tracking inventory as it moves from supplier to warehouse. Shipments can represent complex inbound movement, including containers that split across multiple locations.

Together with purchase orders and suppliers, this gives teams a clearer view of how inventory enters the business.

Suppliers now have dedicated records in Endless. Teams can keep supplier contact details and related supply-chain context in one place, then connect that information back to purchase orders and inbound work.

This gives procurement and operations teams a shared source of truth for the companies they buy from.

Purchase Orders are now available in Endless, giving teams a structured place to track production and inbound commitments instead of managing large orders in spreadsheets.

Each purchase order can track what was ordered, what has shipped, and where coverage is missing, with milestones and status updates to follow progress from supplier commitment through receipt.

Order automations are now available in Endless. Teams can create rules that run when an order is created or updated, then use conditions like customer tags, payment state, marketplace, or other order data to decide what should happen next.

Actions can route orders, apply tags, send email or Slack notifications, call webhooks, or assign safe defaults before an order reaches fulfillment. Automations are available from the admin menu in the sidebar.

Products now have a Sheet View for reviewing and editing catalog data in a spreadsheet-style workspace. Teams can update product attributes inline, move quickly across many rows and columns, and use presets for common views like key product info, dimensions, packaging hierarchy, costs, customs data, and inventory levels.

Sheet View also supports unit conversion, resizable columns, density controls, undo for edits, and collaboration notifications when teammates make changes.

Account and company settings now live in a dedicated settings module in the sidebar. Preferences, notifications, and account details are organized in one place instead of being spread across separate parts of the app.

Integration tools have been redesigned to make connector settings easier to manage. The data mapper has also been improved, making it clearer how external data maps into Endless and easier to keep information flowing correctly between systems.

Team members can now be added directly from a company page. New users receive an invitation email, while existing Endless users can be added to the company immediately.

Users can also belong to multiple companies, making it easier to support teams that work across more than one Endless account.

Endless EDI is now available in beta for retailers and trading partners that require Electronic Data Interchange. The beta supports core retail documents such as purchase orders, advance ship notices, shipping labels, and compliance tracking by retailer.

Teams that need EDI for channels like Target, Nordstrom, and other enterprise retailers can work with Endless to get set up.

Keyboard shortcuts are now available for common workflows in Endless, including moving between modules and records, copying a link to the current page, toggling the sidebar, and using quick search or filters.

The shortcut list is available from the account menu, and more shortcuts will be added as additional workflows are supported.

Product records can now store more of the operational data teams need to manage a catalog: cost analysis, packout details, customer-specific pricing, documents, external links, and product relationships.

Relationships support product compositions, bundles and kits, and variants, giving teams a clearer way to represent how products connect to each other.

Orders can now be cancelled in bulk from the order list. Select multiple orders, use the bulk action buttons, and cancel the selected batch at once instead of opening each order individually.

This is useful when large groups of orders need to be stopped or cleaned up together.

When Shopify changes the assigned fulfillment location for an order, Endless now automatically refreshes allocation. The refresh keeps inventory assigned to the right warehouse as the fulfillment location changes upstream.

This helps keep Shopify-driven orders in sync with Endless inventory before fulfillment starts.

Orders from external integrations now show clearer alerts when fulfillment routing needs attention. Endless distinguishes orders that are fully assigned to external warehouses from orders where an integration requested external fulfillment but local routing is enabled.

The alerts help teams avoid duplicate shipments, missed handoffs, and confusion about which system is responsible for fulfillment.

Allocated orders can now keep changing while inventory stays reserved. Teams can update shipping service, financial information, routing instructions, fulfillment instructions, and third-party shipping billing after allocation.

This lets teams reserve inventory early while continuing to finish the operational details needed before fulfillment.

Teams can now create and manage tasks on individual orders. Tasks live alongside order enrichment details, special instructions, and documents, making it easier to track follow-up work for complex fulfillment.

This is especially useful for B2B orders where several operational steps need to happen before an order can ship.

Sales channels can now require manual approval before orders move into fulfillment. With manual approval enabled, orders remain pending until a team member approves them, even after issues are resolved.

This gives B2B teams a draft-order workflow for preparing orders, reviewing details, and releasing them only when they are ready to process.

Order items now show more detailed statuses as they move through allocation and fulfillment. The added visibility makes it easier to understand what is ready, what is waiting, and where an order needs attention.

Orders can now be configured to allow or block fulfillment before payment is received. This supports B2B workflows where payment may come later, while still letting DTC channels require payment before fulfillment.

The control can be set by sales channel or adjusted on an individual order.

Sales channels can now control whether order items may be assigned to external warehouses. Teams can allow external assignment for channels that already route through outside warehouse systems, or require managed warehouses when Endless should actively handle fulfillment.

The setting can be configured by sales channel and overridden on individual orders when needed.

Shipping methods from integrations can now be mapped directly while working on an order. A customer-facing method like “Free fast shipping” can be mapped to a fulfillment service such as UPS Ground without leaving the order page.

This keeps shipping cleanup close to the workflow where teams discover the mismatch.

When an order arrives from an external system with products that do not exist in Endless yet, Endless can now queue an import for the missing products instead of blocking the order.

Import failures create order alerts, giving teams a clear follow-up path while preserving the order creation flow.

Warehouses imported from Shopify are now created as external warehouses with consistent source tracking. Imported Shopify warehouses are marked as unmanaged, so Endless can represent them correctly without treating them like buildings managed directly in the platform.

QuickView has been rebuilt for deeper operational workflows. You can now open stacked views, follow breadcrumbs back through your path, and keep each view’s scroll, tab, and form state intact while moving between related records.

The panel also has updated layout, spacing, and transitions, making it easier to inspect orders, customers, companies, and other records without losing context.

Shopify order reconciliation now catches orders that may have been missed when webhooks fail or arrive late. Endless periodically scans Shopify for recently created orders, compares them against the orders already in Endless, and imports anything missing.

Webhooks still handle real-time order creation, while reconciliation acts as a safety net so Shopify orders do not slip through the cracks.

The Endless changelog is now live. It gives customers and the team a single place to follow product updates, workflow improvements, infrastructure changes, and customer-visible fixes.

The release-note process is now consistent: changes are written down clearly, dated, and grouped by the part of the business they affect.