Changelog

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.

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.

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.

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.

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.

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.

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.