Version 2026.6

Slot Type DOI Schedules

A small shelf and a full pallet face should not carry the same number of days of stock. Replenishment Policies can now size their trigger and target by the kind of pick face a SKU lives in. Give a Slot Type optional Trigger DOI and Target DOI defaults, then set a Policy's DOI Basis to By Slot Type. For each SKU, ShipStream looks at its highest-priority Location in the Policy's Location Profile and uses, in order, a Policy override for that Slot Type, the Slot Type's default, or the Policy's fallback band. Coverage is still measured across all stock in the Location Profile.

While editing a Policy, the Effective DOI Schedule Preview shows, for each Slot Type in the Location Profile, which band applies, how many SKUs the Policy currently governs there, and how many would not fit at the current Target DOI. The Replenishment Report records each SKU's resolved Slot Type and a Sizing Source that tells you where the band came from. Existing Policies keep Policy (single DOI), so nothing changes until you opt in.

Explore how much stock to carry with an interactive comparison of equal-space, equal-time, and tailored DOI targets against the same pick-face capacities.

Replenishment Lanes and Inventory Position

Replenishment now understands the shape of your warehouse. A Replenishment Lane describes one flow of stock, such as Reserve into Case Pick or Case Pick into Each Pick, with a destination Location Profile, an optional source Profile, and an optional upstream Lane for cascades. Each Replenishment Policy attaches to one Lane instead of naming a Location Profile directly, so the Lane owns where stock goes and the Policy owns the thresholds. A SKU that matches Policies in several Lanes produces a need in one Lane only, and the Replenishment Report shows where else it matched under Suppressed In, so the same demand is never worked twice.

Needs are now measured against Inventory Position rather than the raw quantity on the shelf. Inventory Position counts unreserved stock at the destination and stock that can still be picked, less demand that is already spoken for, so a face full of stock reserved for a wave shows as a real need instead of looking healthy. The report updates as inventory moves, usually within a minute, and a Trigger column explains each row: Min Threshold when the position falls below the trigger level, or Top-off when a Policy's new Top-Off option finds the position below a percentage of target inside a scheduled window. Rows with no recorded demand that a fixed quantity keeps relevant carry a Zero demand advisory instead of disappearing.

Policies also gain Product Overrides for SKUs that deserve their own numbers: a days-of-inventory pair or a fixed minimum and maximum, plus an optional case or pack UOM Product from which ShipStream derives the move multiple. Overrides can be locked, every change asks for a reason, and a full audit history is kept beneath the Policy.

Slotting Density

The best forward-pick space should go to the Products that earn it. ShipStream now scores every Product on how much picking activity it generates for the space it occupies, and ranks it against the other Products in the same Warehouse, Lane, and Merchant on a 0 to 1000 Slotting Density Rank (SDR). A higher rank means more activity per unit of space. Products without reliable dimensions or activity receive a neutral rank so they neither win nor lose contested slots.

Each Warehouse chooses the Rank Formula that fits how it works: Slotting Density (pick visits per committed forward-pick space, the default), Burn Efficiency (units picked per unit of Product volume), or Pick Density (pick visits per unit of Product volume). The new Slotting Density report at Operations -> Slotting Density shows each calculation with its observation window, forward-pick space, how much of it is committed to Products, and the activity behind the numbers, and lets you drill into each Product's rank and any reason it was excluded. Results refresh nightly and are kept so you can compare over time.

Configure Observation Window Days, Neutral SDR, Rank Formula, and Unit Cube Guard per Warehouse at System -> Configuration -> Warehouse -> Stock -> Slotting Density.

Explore who gets first choice of a preferred Location: switch among all three Rank Formulas in the interactive example to see how Product scores and placement priority change.

Directed Put-Away Workflow

Put-away has always relied on the operator to choose a good Location. Directed put-away moves that decision to ShipStream: each Put-Away can be planned into a Directed Tour, a list of stops in travel order that names the destination Location, the Product, the quantity, and the reason that Location was chosen, such as Active home, Open pick-face need, or Best available slot. Planned destinations are limited to Locations a manual put-away would accept, so Slotting Rules, Slot Capacity, lot segregation, and Inventory Holds still apply.

This release ships the workflow controls and the guided tour. Each Warehouse chooses a Default Put-Away Workflow of Manual or Directed, and users with the new Override Directed Put-Away Workflow permission can switch an individual Put-Away from the Scanner's Start screen. When a Put-Away is Directed, Start Tour walks the operator through the route one stop at a time: each stop leads with its destination, the Product, and the planned quantity, a checklist closes as the Product and the Location are scanned, and the counter opens on the planned quantity before the tour advances. A Route view shows what has been placed, what is next, and what is left for manual put-away, and the completion summary lists where everything went. If a destination cannot be used, Can't place here… records a reason and takes the next saved destination or skips the stop for later. When a plan cannot be built, the Put-Away simply proceeds as a manual session. Room that a plan reserves at a destination is held for the tour and released automatically when the session ends or goes idle, so two Put-Aways are never sent to the same empty space. Planning follows a fixed order: an existing home first, then a pick face that needs stock, then the best slot by Slotting Density Rank and pick convenience, with Soft Tiebreakers, candidate limits, and the number of alternatives kept per destination configurable per Warehouse under Warehouse -> Stock. See Put-Aways for details.

Sweep Batches

Floor and lift teams can now divide batch work without racing each other. Sweep replaces Resolve Burn Order Conflicts in the Accessibility choices and selects only Shipments that genuinely require at least one non-pickable Location. Within those Shipments, ShipStream follows Lot burn order, allocates from actual Pickable Locations first, and uses Asset Policy Locations only for the remaining quantity. This includes quantity shortfalls and burn-order exceptions that could previously fall between floor and air workflows.

Batch Presets now have a Default Accessibility setting. An untouched Admin UI dialog and Scanner Next Up, BP: barcode, and Quick Batch flows inherit that default, while an explicit dialog choice still wins for the current run. The Picking Batches grid and batch details also show the effective Accessibility and Asset Policy for later review.

Asset Policy Exclusivity now ignores inventory in Locations that no batch-picking Asset Policy can reach. A reachable non-preferred alternative still prevents exclusivity. None is required when you want the full Sweep population; Partial and Full deliberately narrow it further.

Other Improvements

• Added optional Storage Dimensions to the Product page for Products that take up different space on the shelf than in a shipping carton. Enter Length, Width, and Height in the global base length unit; a complete set replaces the general Dimensions for Slot Capacity calculations, the Slotting Density report, and cubic inventory reporting, while a partial set is ignored. The fields can also be set through the Update Attributes mass action and the storage_length, storage_width, and storage_height product import columns. See Products.

• Added background capture of daily demand and pick-face availability history for each Product and Warehouse. There is no new screen; the data is recorded automatically. After the update, ShipStream backfills the last few weeks of history in the background.

• Moved the Scanner's View Container List button onto the Batch Setup screen, beneath Begin Picking, so a picker can see which containers a batch needs while assigning cart locations rather than only after picking has started. Batches that skip setup, such as single-shipment batches, keep the button on the batch start screen.

Bug Fixes

• Fixed USPS labels via EasyPost failing for oversized packages with "Package was marked as machinable, but is nonstandard", which left affected orders with no way to label until they were moved to another carrier or service. ShipStream now tells USPS whether each package can go through its automated sorting equipment, based on the dimensions and weight submitted with the label, instead of leaving USPS to assume that every package can. Packages shipped in a USPS-supplied container, such as a Flat Rate box or envelope, are unchanged.

• Fixed Product Profiles and Handling Classes misreading Yes/No product attributes such as Requires Packaging and Ship Separate. A product set to No could be evaluated as though it were set to Yes, so products were matched into profiles they did not belong in and — far more often — left out of profiles they did. Classifications are recalculated automatically after the update, so expect a number of products to change profiles. Because Product Profiles select the products that Slotting Rules and Replenishment Policies act on, this can also change where those products are directed in the warehouse.
• Fixed the Copy button in the Global API access-token popup so it copies the generated token.

• Fixed photo upload on Orders and Shipments in the Admin panel turning everyone away with "You do not have permission to upload photos." unless they held full access, even though the same users could add photos from the Scanner. The Admin panel was checking a permission that does not exist in the role tree, so no checkbox could ever grant it. Order and Shipment photo upload and delete now follow Shipping -> Orders -> Actions -> Process, which roles that already hold it gain after the update. Deliveries were never affected.

Global API Updates

The slotting and replenishment configuration layer is now reachable over the Global API, so an integration can provision and maintain a Warehouse's setup as code instead of someone working through the Admin panel.

• Added /v1/inventory/location-tags and /v1/inventory/slot-types with full create, read, update, and delete support. Location Tag deletion is a soft delete matching the Admin panel: Locations already carrying the tag keep showing it, the tag stops being assignable, and PUT {"is_deleted": false} restores it under its original name. Slot Types expose sort_order, patterns, is_fixed_capacity, slot_dimensions, and weight_capacity under fields=all — the existing fields=slot_type embed on Locations is unchanged — and refuse deletion with a used_by detail while still assigned. Locations gained a readable and writable tags field plus POST /v1/inventory/warehouses/{id}/locations/tags, which mirrors the grid's mass actions with add, remove, and replace operations over up to 1,000 Locations per request.

• Added /v1/inventory/product-profiles CRUD, lookup by code, a condition-fields discovery endpoint, and GET /v1/inventory/product-profiles/{id}/products for member Products. Conditions use ShipStream's validated condition format, and responses carry the readable expression, the matched Product count, and the classification status, so a client can poll until a Profile has finished indexing. Re-submitting equivalent conditions does not trigger a rebuild, and deleting a Profile still used by a Slotting Rule or Replenishment Policy returns 422 with dependency counts.

• Added /v1/inventory/handling-classes CRUD and lookup by code, covering Warehouse assignments, sort order, shared Product conditions, and Product Profile membership conditions, with the current classification status on every response. GET /v1/inventory/products/{type}/{id}/classifications returns a Product's assigned Product Profiles and its Handling Class for each indexed Warehouse.

• Added create, update, delete, rebuild, and member-Location endpoints for /v1/inventory/warehouses/{id}/location-profiles, completing a surface that was previously read-only. A Profile's match is an ordered list of AND-ed clauses over the same seven fields the Admin form offers, reads back in a form that can be submitted again unchanged, and is also published compiled to a single expression as match_readable. Writes answer 202 Accepted while membership is rebuilt and 200 when nothing changed; poll until status is ready before pointing a Slotting Rule or Replenishment Policy at the Profile. The previously published revision keeps serving throughout, so a rebuild never interrupts slotting. match is required on create, and a Profile still referenced by a Slotting Rule or Replenishment Policy cannot be deleted.

• Added /v1/inventory/warehouses/{id}/slotting-rule-sets and their nested /rules with full CRUD, POST /v1/inventory/warehouses/{id}/slotting-rule-sets/{rule_set_id}/duplicate to copy a Rule Set within a Warehouse or into another one, and GET /v1/inventory/warehouses/{id}/slotting-conflicts for the Warehouse's current conflicting Rules, conflict-check status, and Rule Set and Rule counts. Duplicates always arrive inactive and report warnings where a Warehouse-specific selector could not be carried across; script criteria are copied unchanged for review.

• Added /v1/inventory/warehouses/{id}/replenishment-policies CRUD plus an options discovery endpoint. Policies list in their real evaluation order, writes are validated with the same rules as the Admin panel, and responses expose Policy subjects, qualification state, the Location Profile reference, and result counters without presenting unpublished values as calculated results. Policies with published Replenishment results are protected from deletion.

• Added GET /v1/inventory/warehouses/{id}/replenishment-index/status and POST /v1/inventory/warehouses/{id}/replenishment-index/rebuild, so an integration can tell whether a Warehouse's Replenishment results are current and ask for a rebuild rather than waiting for the next scheduled one. Rebuild answers 202 with requested_revision (requested_generation before version 2026-08) and coalesces repeated requests, so retrying is safe; it is not available to client Bearer tokens. The Replenishment Report also gained sku, merchant_id, doi_days, and shortfall_qty filters and a sku sort.

• Added Global API version 2026-08. The Replenishment Report gains lane_id, lane_code, lane_name, inventory_position_qty, available_now_qty, serviceable_pick_qty, the stored inventory components, condition_triggers, eligible_triggers, dominant_trigger, desired_level_qty, target_gap_qty, next_evaluation_at, advisories, fixed_min_qty, fixed_max_qty, doi_source, and replenishment UOM fields, with matching filters such as lane_id, dominant_trigger, and advisory. Rows are now identified by Warehouse, Product, and Lane, and shortfall_qty / is_flagged describe the retained physical-coverage figures. Replenishment Policies add qualification_reason value lane_inactive, and the index status reports fresh, catching_up, building, or failed with revision and pending-change counts. Version 2025-07 keeps the previous shape; new filters are rejected on it.

• Added opt-in Slot Type fields trigger_doi_days and target_doi_days; the default Replenishment Policy field doi_basis; opt-in Policy fields slot_type_doi_overrides and results_rebuild_status; and opt-in Replenishment Report fields slot_type_id and doi_source. Policy responses now include doi_basis by default. After recovery is requested for a failed build, results_rebuild_status reads pending until the successor build starts.

• Added cursor paging for every supported sort order on collection endpoints. Sorting by anything other than id previously limited results to a single page; sorted pages now return opaque cursors in the next and previous links and in meta.cursor_start / meta.cursor_end, resuming the walk exactly where it left off with ties broken by id. A plain record id is also accepted as a cursor for sorted collections and resumes from that record's position. Total inventory levels (/v1/inventory/levels/total) also gained the id sort. See paging parameters for details.

• Updated meta.cursor_start / meta.cursor_end to opaque strings whenever results are sorted by a non-id field — including the default order of the inventory levels and rack-types endpoints. Pass the values back verbatim or follow the next / previous links; integer cursors are unchanged for id-sorted collections.

• Removed the label sort option from the deliveries endpoints. It referenced a field that does not exist and always failed with a server error; sort=label now returns a clear 400 Unsupported sort field response.

Merchant API Updates

• Added the inventory:advertised_changed webhook topic so integrations can synchronize advertised inventory directly instead of reconstructing it from Order, Delivery, Inventory Hold, and adjustment events. Each committed inventory update reports Merchant- and Warehouse-level before/after quantities, collapses intermediate changes, and includes up to 500 Products per event with best-effort hold context.