Changelog

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.

Fulfillment orders now have Containers — a real record of how you packed the boxes, pallets, or master cartons that leave your building, one line at a time. Open a fulfillment, add a container, drop items into it, print its label with the shipping container barcode, and mark it closed when the packout is done. Create as many as the shipment needs, and edit or delete a container after the fact if you catch a mistake — you’re no longer stuck with whatever the first save recorded.

Container barcodes (SSCCs) are minted by Endless from your GS1 prefix at save time instead of being generated in the browser, so they’re valid, unique across your company, and stable across reloads. The container’s type — carton, inner pack, master carton, pallet, or generic — is derived from what’s inside it when you close it, and the person who created it is recorded on the record. A container whose barcode isn’t valid GS1 is still saved with a warning rather than rejected, so a scan-in-progress packout doesn’t get blocked at the wrong moment.

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.

The Fulfillment Orders list has a new Apply Rule action. Select the fulfillment orders you want, pick one rule, and apply it to all of them in one go. The batch runs in the background — the app stays usable while it works instead of blocking for the twelve-or-so seconds each fulfillment order used to take.

Progress shows in the list toolbar while the batch runs. Fulfilled and canceled fulfillment orders are filtered out before it starts; anything that couldn’t be processed once the batch is running — wrong company, archived, or already past the point of accepting a rule — is listed with the reason when it ends. Up to 200 fulfillment orders can go through in one batch.

Fulfilling many orders at once is faster. The job that runs each order’s allocation and fulfillment used to repeat the same database work for every order it processed; that cost added up during large bulk fulfillments and kept database locks held longer than necessary. That redundant work is gone across inventory allocation, fulfillment materialization, and the fulfill command’s order validation. Nothing changes about what fulfillment does — just how much it does per order.

Shopify imports now let you pick where the Note from Customer on a Shopify order lands: Instructions (default), Gift message, Both, or Neither. Set it per-integration under Shopify → Orders in the integration settings.

Before this, the note always went to the order’s Instructions. Stores that treat the customer note as a gift message never received it; stores using it for PO / handling instructions were fine. The new setting fixes both directions: pick Gift message and the note lands there instead, pick Both and it’s written to both fields.

Each mode only writes the fields it names, so switching modes never overwrites data in the other field. The audit line on the order timeline (Note from Shopify: …) is preserved in every mode.

Automations can now set fulfillment details automatically when a new fulfillment lands. Pair the new “Set Fulfillment Dynamic Field” action with the “fulfillment created” trigger, pick a field, and set the value once — every fulfillment created under that rule picks it up.

Four fields are supported: instructions, gift message, third-party billing (on/off), and carrier service. Carrier service routes through the shipping-instructions update path so the requested carrier name and id land together; the other three go through the fulfillment-details update path.

Internal notes on Sales Orders, Purchase Orders, and Shipments can now be edited. Each note you wrote shows an Edit action that opens the same dialog you used to add it, prefilled with the current content. Saving updates the note in place and marks it with an “(edited)” indicator so anyone reading the timeline knows it changed since it was posted. Only the note’s author can edit their own notes; everyone else’s stay read-only.

Sometimes an order ends up stuck on the wrong integration — the store’s old connection was replaced, or the integration got reconnected under a fresh record and the order is still pointing at the archived one. It can now be moved.

Open a V2 order and choose Assign source integration (or Change source integration) from the action menu — the command palette has it too. Pick another live integration for the same store from the picker, confirm, and the order is repointed. The new integration takes ownership and, if it supports it, refreshes the order data on its next pass.

A few guardrails so nothing surprising happens: the order has to be claimed locally (not currently owned by another integration), it needs an external order id, and it can’t have active fulfillments. If any of those aren’t in place, the dialog spells out what to fix. Reassignments have to stay within the same integration type. Admin, operator, and order-receiver roles have the permission by default.

Alongside this, skipped Shopify order updates and unsupported order resets now show the actual reason on the order timeline — “authority not held”, “no warehouse”, “reset unsupported” — instead of a generic error.