Changelog

Orderbot is a new way to capture sales orders that come in over email. Every company has a forwarding address ending in @orders.endlesscommerce.com — visible at Settings → Orderbot, on the Sales Orders ⋯ menu, and as a secondary action on the empty Sales Orders state. Forward an order email to that address and Endless turns it into a draft sales order. The primary Add order button is unchanged.

Automations have a new Assign Fallback Fulfillment Carrier Service action. It sets a carrier on a fulfillment that doesn’t have one yet, leaving any fulfillment that already has one untouched. Run it before Assign Fulfillment Profile in the same automation and a fulfillment that arrived without a carrier picks up the fallback first and then auto-processes, instead of stalling because no carrier was set.

Useful when a sales channel — particularly a custom one — doesn’t carry a carrier through on the order, and the same fallback applies regardless of which fulfillment profile ends up running.

Orders V2 — the new order and fulfillment system that most accounts are now running on while it works its way to general availability — picked up a wide round of improvements this week. None of these are large on their own; together they’re the shape of the system getting closer to GA.

Order data. Notes are now real fields on orders and fulfillments instead of being tucked into ad‑hoc data, and Shopify customer notes sync straight into the order note. B2B information lives in its own stable place on both the order and the fulfillment — so reports and integrations can read it without poking around — and the third‑party billing card is gone, with its fields rolled into B2B Info. The order timeline now reads from the system log and labels every event as System, Human, or coming from a connected integration.

Editing in‑flight orders. Item edits used to be blocked outside of draft. They’re now allowed in any non‑cancelled state, and lines that aren’t tied to an active fulfillment can be edited even when the order is in progress or already fulfilled — so a correction on a live order doesn’t require walking it backwards. Items that came in marked Not in catalog can be re‑matched by SKU, linked to an existing product, or turned into a new catalog product on the spot. Pending orders with an unrecognized SKU no longer get blocked from acceptance.

Fulfillment. The Refresh Order button works on V2. Fulfillment profiles can be assigned even on in‑progress fulfillments, and the Create button shows up when none exist. The Mark Fulfilled action stays visible (enabled only when the fulfillment can actually be marked or is running through a profile). The fulfillment integration button now points at the right system. The availability panel reads from an order‑scoped source so it loads on large orders. Cancelled orders no longer show an empty Items to Fulfill section. The metadata tab is cleaner, with external ID editable inline. Endless Window fulfillment profiles got a coverage follow‑up. Sales order details auto‑expand the sections that have content.

Shopify on V2. Several Shopify edge cases stopped surprising people: fulfillment state no longer slides backwards, cancellations propagate to Endless, digital order lines and fulfilled counts line up correctly, and near‑simultaneous webhooks can no longer duplicate a shipment. Cleanup tasks are bundled in for orders the bugs already touched.

We’ll start logging V2 changes individually once the beta closes; while it’s still in flux this often, grouping reads better than enumerating.

A fulfillment can now carry an assigned supplier. The fulfillment detail page has a new Supplier card to assign, change, or remove the supplier; fulfillments with a supplier present show a Dropship badge, and the fulfillment orders list gains supplier and Dropship columns and filters. The underlying record stays neutral — it’s an association to a supplier — so the same data can later be reported on by supplier without a redesign; the Dropship treatment lives in the UI.

The ShipStation sales-channel mapper no longer asks operators to paste in a raw store ID. On a ShipStation integration’s Data tab, Add Mapping is now Manage Mappings, which opens a modal that fetches your stores live from ShipStation and shows each as Store ID, Store Name, and the sales channel it’s mapped to. Existing mappings appear at the top, read-only; unmapped stores appear below with a sales-channel picker. Re-fetching the list never duplicates a store you’ve already mapped.

The store name is saved alongside the mapping, so reports and detail pages can show the human-readable name. The free-text edit pencil has been retired for ShipStation rows — to change a mapping, delete it and re-map through the modal, so the store ID and name can’t drift apart.

This is what last week’s channel-listing work was for. Any other integration that exposes a list-channels capability gets the same shape automatically.

Packiyo is now a connected fulfillment integration. Set up the connection from the integrations settings — the new Packiyo tile takes a per-brand bearer token and a tenant URL — and once it’s saved, Endless pushes allocated fulfillments to Packiyo as orders and records shipment and tracking back automatically: by webhook in normal operation, with a scheduled backstop that picks up anything the webhook missed.

This is the first phase of the Packiyo integration; it covers authentication, ship-order push, and shipment sync.

Purolator is now selectable as a system carrier alongside the other system carriers, so brands shipping with Purolator can pick it on shipping methods and fulfillments without a custom carrier setup.

Instructions written on a fulfillment now travel to ShipHero. What an operator types into a fulfillment’s instructions arrives as the packing note on the ShipHero order, so the person packing the box sees it.

A fulfillment with no instructions of its own falls back to the order’s note, which is what ShipHero received before. Nothing needs setting up, and it applies to every order sent to ShipHero from here on.

Two changes to how Shopify orders connect to products in your catalog.

The “Import products” action on a Shopify integration always works now. Before, the action was silently blocked on integrations whose product-import setting was off, so the only way to pull in products was to turn that setting on first. Whether to import is your call from the UI; nothing else gates it.

The same setting still exists, but it now controls a narrower behavior: whether Endless should automatically import a missing product when a Shopify order comes in referencing one. The default is off, so order ingest no longer creates products on its own unless you opt in. Integrations that already had this setting on stay opted in.

Regardless of that setting, an order item that arrived without a matching product is now linked to one as soon as the product shows up — created later, imported manually, or updated with the SKU the order is referencing — so an order that landed before its product did doesn’t stay orphaned. V2 orders behave the same way as V1.

EDI 850 orders coming in through the Orderful path could fail to import on every order when the inbound template didn’t include a shipping carrier service. Order creation was rejecting the input outright, even though the carrier service is supposed to be set later at fulfillment, not on the inbound PO.

EDI 850 orders without an inbound carrier service now import as expected. Any carrier mapping the template does send is still picked up.