Version 2026.5

2026.5TBD

Merchant-Scoped Allowed Countries

The Allow Countries setting can now be set per Merchant, so a 3PL serving clients with different international footprints no longer has to settle on one global list. Set a Merchant-specific list at System -> Configuration -> General -> Countries Options by switching the configuration scope to that Merchant; Merchants without an override continue to inherit the global list.

The Merchant's own list is honored everywhere destination countries matter: the country selectors on Admin and Client UI order creation, order validation through the APIs, and the destination check at shipment time — so an order accepted for one Merchant is never blocked later by another Merchant's settings.

Update Impact: None. All Merchants keep inheriting the global list until you set a Merchant-scope override.

Harmonized System Code Terminology and Export Disclaimers

The product Export tab now uses standard customs terminology so the fields match what you'll find in classification databases and carrier paperwork. The field previously labeled HTS Base Code is now Harmonized System Code — the 6-digit internationally standardized HS code in the format ####.## (e.g. 8471.30) — and HTS Country Code is now HS Code Extensions, the country-specific extensions to the 6-digit code (for imports into the United States, the last 4 digits of the 10-digit HTS code). Updated notes under each field explain the expected format, and product imports accept the new column names hs_base_code and hs_country_extension while the legacy column names continue to work.

The rename goes all the way down: the product attribute codes themselves are now hs_base_code and hs_country_extension, matching the field names already used by the Global API. The legacy hts_* names remain accepted at every external boundary — Merchant API input, product import columns, and plugin rate/shipment payloads — so existing integrations, saved import templates, and scripts keep working.

The Export tab (in both the Admin and Client UI), the export and customs configuration sections, and the Regulations screens now also display disclaimers clarifying that you are responsible for the accuracy of export classification data and for compliance with shipping regulations.

Update Impact: Low. Attribute values, import files, and API integrations continue to work unchanged. Merchant API clients that request the attribute by its raw code via the generic attributes selector should switch from hts_base_code/hts_country_code to hs_base_code/hs_country_extension; the standard product.info response includes both key sets.

Replenishment Policies and Location Profiles

Keeping pick faces stocked has always depended on someone noticing they're running low. ShipStream can now watch for you: define Replenishment Policies with a Trigger DOI and Target DOI (days of inventory), and ShipStream flags every SKU whose coverage in a chosen set of locations has fallen below the trigger — including SKUs that are selling but were never slotted there in the first place.

Location Profiles (Operations -> Warehouse -> Location Profiles) are named, reusable sets of Locations defined by match criteria such as Zone, Rack, or Location Tags. Slotting Rules and Replenishment Policies share them, so one "Forward Pick" definition can serve both, and the grid shows exactly which rules and policies use each profile.
Replenishment Policies select SKUs by Merchant, Product Profile, or Handling Class and pair them with one Location Profile and a days-of-inventory band: when a SKU's coverage — its on-hand in the profile divided by its recent daily pick rate — drops below Trigger DOI, it is flagged with the quantity needed to restore Target DOI. Policies are evaluated in your chosen order, and the first matching policy governs each SKU.
The Replenishment report shows each flagged SKU with a Replenish status (stocked in the profile but below trigger) or Slot status (selling, but not yet assigned a location in the profile), along with its current days of inventory, the suggested move quantity, and how much stock is available elsewhere in the warehouse to cover it.

SKUs that Slotting Rules forbid everywhere in the profile are excluded automatically, so every flag is one your team can act on. Together with Slot Capacities, this lays the groundwork for directed put-away guidance.

Update Impact: Existing Slotting Rules are migrated automatically — each rule's location criteria become a shared Location Profile (identical criteria are consolidated into one profile) with no change in enforcement behavior. New permissions are required, so add Operations -> Warehouse -> Location Profiles and the new Replenishment resources to your appropriate roles.

Smarter Packing Weight Checks

The packing weight check now uses a tolerance band instead of a single flat percentage, so it can be sensitive enough to catch a missing item in a small package without flagging normal variance on a heavy one. The allowed difference is a percentage of the expected weight, kept between a new Weight Check Difference Minimum and Maximum, and widened to your scale's precision so a coarse scale's rounding never causes a failure on its own. When a check does fail, the packer now sees the measured weight and the exact accepted range instead of a percentage, making it much easier to spot what went wrong.

Configure the band per merchant at System -> Configuration -> Warehouse -> Scanner -> Packing (defaults: 4%, 0.1 lb Minimum, 2 lb Maximum) and set each warehouse's Scale Precision under Scanner -> General to match its scales. The Minimum, Percentage, and Maximum can also be tuned for individual Shipments from a Packing Start Script. See Packing Weight Check for the full details.

Update Impact: The default tolerance is tighter than before — the old flat 15% default is replaced by the band defaults above, and the allowed difference is now capped by the 2 lb Maximum even where a higher percentage is configured. Most merchants will simply see more mispicks caught, but if you intentionally rely on a wide tolerance for heavy packages, raise the Weight Check Difference Maximum after the update.

DHL Express via EasyPost

DHL Express is now available as an EasyPost-backed carrier, bringing international express shipping — DHL Express Worldwide - Documents and DHL Express Worldwide - Non Documents — into the same setup flow you already use for other EasyPost carriers: enable the carrier, choose EasyPost as the Integration Provider, attach a DHL Express carrier account from your EasyPost dashboard to a Shipping Account, and select the allowed methods. Labels, customs documents, tracking, and refunds all flow through EasyPost, and both services are available as methods on merchant rate plans.

Customs paperwork is handled automatically per service: Non Documents shipments send your full commercial customs data, while Documents shipments are declared as documents built from the actual package contents — no product customs data required. Sender Tax IDs (VAT, IOSS, VOEC) are passed along as well.

Shipments are validated against DHL's current published limits before a label is attempted, so an oversize package or an over-weight Documents shipment (the Documents service is limited to 4 lb / 2 kg billable weight) is rejected up front with a clear message instead of a cryptic carrier error. Section II lithium-battery shipments (PI966/PI967) are declared automatically based on the products' hazmat settings.

Update Impact: This replaces the legacy DHL Express integration, which was built on a DHL API that has since been discontinued. The DHL Express carrier is disabled by this update; to resume (or start) shipping with DHL Express, add a DHL Express carrier account in EasyPost, attach it to your ShipStream Shipping Account, and re-enable the carrier. Country filters, warehouse restrictions, tracking-number requirements, and debug settings are preserved.

Automated Order Cancellations via EDI (SPS Commerce)

When a trading partner cancels a purchase order over EDI, the cancellation no longer sits in an error queue waiting for someone to notice — with the risk that the canceled order ships in the meantime. The SPS Commerce integration now processes inbound Orders documents with TsetPurposeCode 01 (Cancellation) automatically, matching them to the Order created from the original EDI document and acting according to a new per-subscription Order Cancellation Policy:

Immediate Only - The Order is canceled outright; if it cannot be (for example, fulfillment is already underway), the document is flagged for manual handling.
Immediate with Cancellation Request fallback - Orders already being fulfilled receive a Cancellation Request instead, so warehouse staff decide whether to stop the shipment or let it go.

A cancellation that arrives for an already-canceled Order is treated as success, and one that arrives before the original order document has finished processing is retried automatically.

With the companion Send Cancellation Ack option enabled, an 855/OrderAck reports the outcome back to the trading partner — sent only once the outcome is final: the Order is canceled, or the cancellation request is rejected because the Order shipped anyway.

Update Impact: None. The Order Cancellation Policy defaults to Prohibited, which preserves the previous behavior. Enable automatic cancellations per Merchant Integration subscription under Subscription Configuration.

Slot Capacities

Answering "how full is my warehouse, really?" requires knowing not just what is on each shelf, but how much could be. This release lays that foundation: ShipStream now computes how many units of each product fit in each kind of slot, automatically, from the dimensions you already maintain.

Stock Location Types are now Slot Types. The clearer name reflects what they describe — the physical slot on the rack. The rename carries through the admin menus, grids, the Stock Locations import, and the Global API, and your existing role permissions are updated automatically.
Slot Types can declare their physical capacity. Enable Fixed Capacity on a Slot Type to record its interior Width, Height, and Depth, plus an optional Weight Capacity.
Capacities are computed for you. For every product and fixed-capacity Slot Type, ShipStream determines how many units fit using the product's dimensions, weight, and Can Tip setting — a volumetric estimate governed by a configurable Volumetric Efficiency (default 90%), sharpened by the ShipStream Packer bin-packing pass, and optionally refined further by Paccurate. Products and slots that share the same physical profile share one result, and capacities recompute automatically when dimensions change.

Computation methods are configured at System -> Configuration -> Warehouse -> Stock -> Slot Capacity. These per-product capacities set the stage for slot utilization insights and smarter put-away guidance built on top of them.

Update Impact: If you import stock locations from a spreadsheet, update saved files to use the Slot Type column header (previously "Location Type"). API integrations that read or assign a location's type must adopt the renamed field — see Global API Updates. No permission changes are needed.

Other Improvements

Added an hs_base_code field to the External Shipping Method API rate and shipment request payloads alongside the legacy hts_base_code field, which remains supported as a deprecated alias.

Bug Fixes

Fixed Delivery processing on the Scanner counting against the wrong line when a Delivery listed both the case SKU and the singles SKU of the same Quantity-type product. Scanning a singles barcode opened the case line and counted a fraction of a case, leaving an overage on one line and a shortage on the other. Each barcode now counts against its own line, and the counter still accepts either barcode when only one of the two SKUs is on the Delivery.

Fixed the Scanner Allow Partial Batches toggle not flagging a Preset + Asset Type selection as unfillable when the cart is limited by weight or volume (for example a Steel Picking Cart). With Allow Partial Batches off, those selections now grey out Quick Batch / Next Up and show "Not enough shipments to create a full batch" as soon as the entire matching queue cannot reach the cart's weight or volume cap — not only when the shipment count is short of the cart capacity.

Global API Updates

Updated the Location resource: the location_type reference is renamed slot_type, and its resource type LocationType is renamed SlotType. This applies to responses, create/update requests, and include/fields/sort/filter parameters on the warehouse locations endpoints. Requests using the old names are rejected, so update integrations alongside this release.

Merchant API Updates

Added hs_base_code and hs_country_extension fields to product info responses alongside the legacy hts_base_code and hts_country_code fields. Product create and update accept either naming (when both are supplied, the hs_* value wins), and the legacy hts_* field names remain supported.

Added a containers property to the delivery:committed and delivery:complete webhook payloads so integrations can capture container-level contents and lot quantities at commit/complete time without a follow-up delivery.search call. Each container matches the existing delivery.search container shape (contents with per-lot qty_counted and qty_shortage); lot-tracked content also includes the commit quantities qty_processed, qty_putaway, and qty_committed, which are webhook-only and are not added to delivery.search. The array is always present and may be empty.

Added an optional details array on each SKU row in stock_adjustments for the inventory:adjusted, delivery:committed, and delivery:complete webhook payloads (and any other topics that include stock_adjustments). Each detail breaks the adjustment down by lot_id and either adjustment_reason_code or hold_reason_code; hold/release details also include qty_held. SKU-level qty_adjust is unchanged and equals the sum of its details. details is omitted when there is no lot or reason breakdown.