Changelog

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.

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.

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.