Changelog

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.

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.

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.

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.

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.