Changelog

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.

When an integration cannot complete something, the failure recorded against it now says what could not be done and for which integration or order, in one sentence. The provider’s raw response is kept alongside for whoever needs to dig into it, rather than filling the line you read first.

This covers Shopify inventory, missing products on orders imported from Shopify, Skubana and Cin7, ASN sync with Gobolt and InfoPlus, inventory sent to Sellbrite, orders shipped through Trackstar, and EDI documents. Two failures that never made it onto the record at all — some Gobolt and InfoPlus responses, and a missing-product case from Shopify — now do, and Trackstar failures are no longer labelled as InfoPlus.

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.

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.