Skip to main content
Start with a shipment you can create and inspect locally. This walkthrough creates a two-unit order, records a simulated dispatch and delivery, and checks the shipment, order, and inventory separately. Then use the warehouse contracts below to plan wave, pick, pack, and ship tasks. The example uses @stateset/embedded 1.35.1. It buys no label, contacts no carrier, and sends no customer notification.
In this version, changing a shipment’s state does not automatically fulfill its order or consume its inventory reservation. Shipment methods also accept out-of-sequence changes: do not rely on them to enforce your dispatch and delivery policy.

Prerequisites

Use Node.js 20.20.0+ and npm 10+:
See SDK installation for native-module troubleshooting.

Run the complete example

Save this as shipping-demo.mjs:
Success: all assertions pass and the output is:

Understand what the example proves

The early-delivery rejection comes from our recordDelivery function. The direct SDK shipments.deliver call in this version accepts a pending shipment. The wrapper demonstrates where to enforce a policy; its separate read and write do not protect against concurrent writers. Coordinate event processing for each shipment and enforce permissions in your service. The published CreateShipmentInput links an order but has no item-quantity array. This example does not demonstrate partial fulfillment or item-to-carton allocation. Keep shipment IDs, order IDs, warehouse task IDs, and carrier tracking numbers distinct in your integration.

1 — Build and release a wave

A warehouse wave groups orders for processing. Use the wave creation contract and release contract for your deployed service. Verify its warehouse ID, selected orders, and generated tasks before allowing workers to act. The Node SDK 1.35.1 fulfillment surface accepts warehouseId and orderIds when creating a wave. It also exposes wave reads, release, completion, and cancellation. Do not infer full warehouse workflow coverage from the existence of these methods.

2 — Pick

Use the pick task list and completion contract to determine the exact fields supported by your warehouse service. Record physically counted quantities and resolve shortages through the configured exception process. The published Node Fulfillment class exposes pick reads, assignment, start, and cancellation, but no pick-completion method. Do not invent fulfillment.completePick in an embedded program. Choose an interface that supports the required operations before building an end-to-end flow.

3 — Pack into cartons

Use the carton creation contract and pack completion contract for the service owning warehouse packing. Retain order-line quantities, carton IDs, and the shipment relationship in that system. The local shipment example above creates no cartons. Verify packing and label purchase separately. A carton record does not prove that a carrier accepted a label request or took custody of the package.

4 — Ship

The warehouse ship-task completion contract is a different surface from the local shipments.ship method demonstrated above. Check its request shape and the side effects of your deployed service. Record dispatch from the evidence your operation requires, such as carrier acceptance. Retain that event’s identity and the connector outcome. Verify order fulfillment, inventory consumption, channel synchronization, and customer notification separately; do not infer any of them from a shipment status alone. The order lifecycle reference describes order operations, which are separate from these shipment updates.
The HTTP references require a deployed commerce service. Start with the local example when you do not have one; use the API directory to choose a service and its authentication contract.

Handle retries and out-of-order events

The published Node shipment create/ship/deliver signatures have no idempotency-key parameter. Retain the shipment ID against your external fulfillment request and reconcile an uncertain creation before creating again. A tracking number is not a substitute for that mapping. For carrier events, retain the event identity and observed shipment state. Process duplicate and late events according to an explicit transition policy. A late dispatch event must not silently regress a delivered shipment. After a timeout, inspect stored state and original event processing evidence before another write. See error handling and retries.

Give an agent a fulfillment task

A read-only task should include the order and shipment IDs and ask for shipment state, order fulfillment state, inventory, and the available carrier evidence as separate findings. For a write task, specify the allowed transition and its evidence requirements. Authorizing a shipment update does not authorize buying a label, capturing payment, or sending a notification. Discover actual tool schemas, use the configured permission policy, and return record IDs plus read-back results. Use the agent operating procedure and connection guide to define the task boundary.

Watching the floor

Monitor pick tasks, pack tasks, and ship tasks in the owning service. Queue age and repeated failures identify work needing investigation; queue depth alone does not establish whether staffing, inventory, packing, or carrier availability caused a delay.

Troubleshooting

Last modified on September 20, 2026