Changelog

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.

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.

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.

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.

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.

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.

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.

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.