@stateset/embedded 1.35.1. For a complete executable program
with stock assertions, start with the inventory quickstart.
Create an item and read stock
getStock(sku) returns null when there is no matching item. Check for that result before
reading quantities in application code.
Reserve, then confirm or release
The reservation API uses positional arguments:reservation.id. Choose the next action based on the workflow outcome:
These are separate outcomes, not two consecutive steps in a successful checkout. Confirmation
records acceptance of a reservation; it is not a stock-consumption operation.
Expiration and retries
The optional fifth argument sets an expiration timestamp. Omitting it creates a hold without that timestamp. Expiration is checked by engine operations; do not assume the Node process runs a background timer that releases every expired hold at the deadline. Confirm before the deadline and handle an expired-reservation error as a failed confirmation. Reconcile the current checkout state before attempting another hold. Explicitly release known abandoned holds instead of relying on elapsed time alone. A payment-provider timeout leaves the external outcome uncertain. Reconcile that provider’s result before releasing or replacing stock; a generic catch block cannot distinguish a confirmed decline from a charge whose response was lost.Adjustments
For a counted correction or damage, use a signed quantity delta:(sku, quantityDelta, reason). It adjusts on-hand stock; it does not confirm
or release a reservation. Read getStock afterward to verify the resulting quantities.
Order and return integration
The orders quickstart verifies creation and cancellation. Avoid
reserving the same units manually as well. The
returns workflow explains the
published binding’s disposition limitation before completion.