Skip to main content
Start warehouse onboarding with one measurable task: record ten expected mugs, receive four, then receive the remaining six. Verify the shipment state after every change and reject an attempt to receive more than expected. This program uses @stateset/embedded 1.35.1 in a fresh local database. No hosted API key, carrier connection, or warehouse service is required.
In this version, inboundShipments.receiveLine updates the inbound shipment’s received quantity and state. The program verifies that it does not increase inventory on hand. Posting sellable stock and assigning a warehouse location are separate integration work.

Prerequisites

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

Run the complete example

Save this as receiving-demo.mjs:
Success: all assertions pass and you see:

Understand the identities and quantities

Use the returned shipment item ID, not the product ID, as the second argument to receiveLine(shipmentId, itemId, quantity). Quantity inputs and received totals are decimal strings. The received quantity is cumulative, but each call supplies an additional quantity: four followed by six yields ten. Sending ten after the initial four would exceed the expectation. markArrived records arrival; it does not count the contents. The partial and final receiving calls record the quantities counted for the line. This example has one line; inspect all lines when adapting it to a multi-item shipment.

Handle retries and discrepancies

This method’s published Node signature has no idempotency-key parameter. Do not treat an identical receiveLine call as a read or an overwrite: it adds another quantity when accepted. An excess-quantity guard is not duplicate detection; a repeated small receipt can still fit within the expected total. Keep a durable identity for each physical receiving event in your integration, together with its shipment/line IDs, counted quantity, and outcome. If the call’s result is lost, reconcile the original event and stored received quantity before sending another delta. Coordinate writers so two workers do not independently apply the same scan or delivery event. A mismatch between expected and counted goods needs an explicit operational decision. Do not change the count to make the shipment look complete. Report damaged, missing, or excess units to the process that owns disposition and supplier follow-up.

Keep receiving and stock posting separate

The final shipment is received, while inventory.getStock still reports zero. The example has neither posted stock to a bin nor updated a purchase order, supplier bill, or external WMS. Do not tell another agent that these units are sellable based only on the shipment status. Choose the receiving and inventory process your system actually uses, map its record IDs, and verify both outcomes. Simply following every receipt with inventory.adjust would introduce a second write whose retries and failure recovery you must design; it is not an atomic receiving transaction supplied by this example. The receiving and put-away guide distinguishes these records and points to the relevant contracts. The inventory quickstart shows stock adjustments and reservations separately.

Give an agent a receiving task

For a read-only check, supply the actual shipment ID and ask the agent to report its status, each line’s expected/received quantities, and separately observed inventory. Have it identify the tool results behind its answer. Do not infer stock availability from the receipt total. For a write task, also supply the exact line ID, the additional quantity physically counted, the receiving-event identity, and the configured authorization for that operation. Discover the installed server’s tool schema rather than translating these Node method names into guessed MCP tool names. Use the agent operating procedure.

Troubleshooting

Next steps

Last modified on September 20, 2026