Changelog

You can now edit the API token on an Amazon integration from its settings. Update the token when Amazon issues a new one, or after rotating credentials, without removing and re-creating the integration.

Shopify still keeps its API token locked, because it is issued through the Shopify install flow and rotating it there would not update Endless.

When a B2B order split into fulfillments going to different destinations, warehouse integrations and EDI documents read the retailer’s PO, vendor, department, distribution center, ship window, and routing straight off the order, so every split fulfillment shipped against the order’s original destination. Each fulfillment now carries its own effective data — its override where one is set, the order’s where it is not — and every warehouse payload and every EDI 856 and 810 scoped to a single fulfillment reads that. A fulfillment with no override produces the same payload as before. Third-party billing carrier can be overridden per fulfillment as well; special instructions stays on the order.

The EDI tab on any order carrying a store distribution has a Store Packout Plan section showing the plan the retailer sent. Items are rows and stores are columns, with the item pinned left and its total pinned right, across three views: As Ordered from the purchase order, As Packed rolled up from every fulfillment’s containers, and Variance between them. Filter by distribution center and store, search by SKU, name, UPC, or purchase-order identifier, and download exactly the view you are looking at.

When the order splits, the plan groups by fulfillment order. Each becomes its own collapsible section headed by its number, distribution center, and store and unit counts, holding only the stores it ships — a purchase order across six distribution centers reads as six sections rather than one 87-column table, and two fulfillments shipping the same store stay apart instead of merging their units. A Fulfillment Order filter appears when the order is split, the CSV carries a Fulfillment Order column, and an unsplit order renders as it did. Two things to know about the numbers: store distribution lines match order lines on the purchase-order line identifier both sides already carry, so any identifier scheme resolves, though orders imported before this change keep the previous matching path; and a quantity that could not be restated in eaches is treated as unknown rather than zero, so it stays out of every total and Variance does not read as a full overage.

Import Order From Integration now covers Endless EDI. Search a retailer’s purchase order number, see the matching 850s with an In Endless or Not In Endless badge, and import one from the same dialog you already use for the other integrations. The retailer’s PO number is the only searchable field — everything else on the vendor side is envelope data, and there is no search into the message body.

An imported 850 runs through the same processing an incoming poll does, so the order lands exactly as a polled one would and the acknowledgement and shipment documents read it the same way. Re-importing an 850 that is already in Endless deduplicates against the existing order rather than landing beside it, and a purchase order that is already an order is skipped, so a partner resending under a new transaction id does not create a second copy.

Running Update Fulfillments on a Shopify order that had already fulfilled its add-on lines — shipping protection, carbon offsets, and similar non-physical items — errored out instead of reconciling against what was left, so any split, move, or merge spanning the add-on was blocked.

Update Fulfillments now plans against the quantities Shopify still shows outstanding, ignores lines with nothing remaining, and leaves already-shipped add-on lines alone. Two cases that used to give a generic failure now say what to do about them: a partial quantity spanning more than one Endless fulfillment, and Shopify having more remaining than Endless has planned. An unrelated hold on the order no longer blocks a valid plan.

A product’s External Identifiers card shows a Not Linked badge when an identifier has no integration behind it. That badge is a button now: click it, pick the integration, and the identifier is linked — without leaving the product to find the action on the integration’s detail page.

Linking is catalog-wide. A partner name maps to one integration for the whole catalog, so linking from one product links every unlinked identifier under that partner name. The dialog says so before you confirm, and the row flips to Linked once the job finishes.

Sales receipts and invoices put freight on QuickBooks’ own shipping field rather than on a line item, so document totals separate merchandise from shipping the way QuickBooks expects. A setting on the integration controls whether Endless uses that field, and saving it checks what your QuickBooks account reports — turning it on for an account that has the field off is refused at save time rather than failing on the next push. Item descriptions are no longer sent on receipts and invoices; the product name is what appears on the document.

Two new settings set defaults for what Endless sends: default payment terms on invoices, and a default deposit account on sales receipts. Leave either empty and QuickBooks applies the customer’s default or Undeposited Funds. Both can be overridden per document from the accounting card on an order, and a document that inherits shows the default by name — “Net 30 (default)”. Pushed documents carry line descriptions from the accounting item’s sales description, falling back to the SKU. The Send button is now Push To QuickBooks, the Sent To QuickBooks badge opens the document directly in QuickBooks, and an Items Linked badge in the card header, with Linked and Unlinked badges per line, says whether every line resolves to an accounting item.

Importing matches better in two places. A product whose first mapping field is ambiguous is resolved by a later mapped field when the two agree; a genuine conflict stays unlinked and is written to the integration log rather than silently skipped. Customers and vendors match on display name, which is what QuickBooks uses to keep records unique, so a record sharing an email address with another one imports instead of being dropped. Run Import Terms once per QuickBooks integration after this deploys to fill in terms imported earlier.

Veracore now handles the full supply-shipment loop. A shipment sent to a Veracore-backed warehouse posts as an expected-arrival record, and the key Veracore returns stays on the Endless shipment for reconciliation. Received quantities come back through Veracore’s Expected Arrivals report on the same daily schedule the other warehouse integrations use, and a shipment closes when every line is fully received. Veracore’s owner ID is derived from the System ID already on the integration, so there is nothing new to configure. A missing System ID or Expected Arrival Date is reported before the send is attempted rather than as a generic failure afterwards, and re-sending the same ASN is safe.

Veracore integrations also get a Lot Tracking toggle. With it on, each ASN line sends the shipment item’s lot number as the product version Veracore reads, so a receiving warehouse keeps the lot on record. Pull Inventory branches on the same flag: lot-tracked accounts submit the Product Detail with FIFO report and each SKU version is mirrored into its own warehouse location, with Default Available zeroed so a versioned SKU is not double counted. Non-lot-tracking accounts are unchanged, and a partially versioned account still reconciles — rows with a blank version fall back to a single total on Default Available.

Business Central appears on the listings surface with product publishing available. The publishing table reads its rows from the integration, and each row shows the caption an operator sees in Business Central — Search Description, not Search_Description. Fetch Attributes and Auto-Map are on the attribute mapper, so a field is picked from a live list instead of typed, and a saved mapping shows up in the publishing table without a page reload.

A push no longer loses everything to one refused field. The item card write is a single request, so any field Business Central rejects used to take the whole card with it. The push now reads the refusal, drops the field it names, and retries with the rest, up to four rounds — what lands is every field Business Central accepted, plus a note on the product naming what was refused and why. Four more Endless attributes pair to fields on the card and are ready to enable: landed cost, packaging URL, specs URL, and shipping weight. Each is off by default, because another system may already be writing those fields; turn one on when you have decided Endless is the source. When a call does fail outright, the operator reads Business Central’s own message — a wrong or blank environment, bad credentials — rather than a generic parser error.

The two halves of “wipe a bad copy of an order and pull a fresh one” now line up.

Import from your integration, directly from the Sales Orders list. The Add control on the Sales Orders list is a menu now — Manual Order or Import From Integration. Import From Integration takes the external order reference you already recognize (for example, a Shopify order name like #1104) and shows every match across the integrations you have connected, with each one labelled as either already in Endless or ready to import. Picking a match already in Endless takes you to that order; picking a new one pulls it in through the same import path new orders normally take, and refreshes the list when it lands. The first-run empty state on the list carries the same import action. The field reads Order reference and, once you pick an integration, an optional hint tells you what to type — for Shopify, either the displayed order number (including any prefix or suffix your store uses) or the full Shopify Order GID; both are accepted. Only integrations that support lookup and single-order import appear in the menu; today that is Shopify.

Delete, including legacy orders. Deleting an order now covers legacy orders too, using the same typed confirmation and the same background progress the newer flow uses. Delete works from an individual legacy order’s detail page and from the Actions menu on the Sales Orders list, including bulk selections and mixed sets of legacy and newer orders. Two small races on the delete path have been cleared up along the way: QuickView no longer briefly flashes “Order not found” after a delete when a background refresh was still in flight, and a bulk delete no longer errors when a sales-channel lookup is still finishing on a row you are removing.

Put together: find a bad copy, delete it, look it up again by its integration reference, and pull a clean one in — from one list, without leaving it.

A broad pass across the Shopify integration. Everything below is live and connected accounts benefit automatically.

Order sync is one setting, starting from here. Import & Update Orders replaces the topic-level toggles and a legacy Manage Orders Locally setting. Turning it on connects the webhooks and starts polling from that moment, so a first-time connection stops pulling a day of back-history in as if it were current activity, and a late webhook against an older order that was never in Endless no longer conjures it into the list. New orders carry the store’s processed date as their Endless order date instead of ingest time. Manual and bulk import are still the way to bring history in.

Cancellations behave the way you’d expect. Canceling in Shopify now cancels a fulfillment that is still in draft or allocated; if fulfillment has moved past those states, Endless refuses the source cancellation instead of unwinding work in flight. A Shopify replacement — original canceled, new one issued — retires the canceled work at import instead of carrying it in as active. Historical orders that were already canceled before Endless first saw them come in canceled directly, with none of the “new order” side effects. Any canceled order with no successful fulfillment lands canceled the same way. On active orders, line quantities reflect what actually happened: units shipped plus units still owed, with pre- and post-fulfillment refunds netting out correctly.

Multi-fulfillment imports land in full, or fail cleanly. Importing an order with more than one closed fulfillment used to partially succeed — the first transferred authority to Endless and the rest failed silently. Closed fulfillments now stay ready until their shipments come across, and the order completes when the recorded shipments cover every unit; partial coverage stays incomplete, and a failure surfaces as a real error. On the related failure mode, closed and non-handoff fulfillments now ingest before any in-progress one takes authority, so an in-progress fulfillment no longer rolls the whole import back.

Inventory and SKUs track the current state. When Shopify is a building’s inventory source, physical stock in Endless follows what Shopify records as on-hand instead of what it reports as available, which had made items look emptier than they were and could send Endless below zero. Damaged units still go to Default Unavailable and are no longer counted twice. Order lines now come in with the current variant SKU when Shopify has one, so a rename in Shopify no longer leaves the sales-order line and its fulfillment inventory item pointing at different SKUs for what is the same variant.

Support: bulk historical order import. A preview-first support task can now pull a date-bounded cohort of Shopify orders back through the normal ingestion pipeline for account recoveries, skipping anything already in Endless.