Order Lifecycle
The full path an order takes through the embedded engine, and the calls that move it.
The engine runs in-process β thereβs no server to start and no network hop.
1. Create the order
Start minimal, then enrich with payment, shipping, and customer detail as the checkout collects
it.
2. Reserve inventory
Reservation is a three-step protocol, not a single write:
Reserve before authorising payment, confirm after. Reserving first prevents an oversell in the
window between the two. Confirming after means a declined card releases the stock instead of
stranding it.A reservation that is neither confirmed nor released holds inventory indefinitely β always pair
the call with one of the two outcomes, including on your error path.
3. Validate and authorise payment
Validate totals, tax, and discounts before authorising. For agent-driven flows the action should
be explicit and auditable β see the decision gate for how
consequential actions get approved.
4. Fulfil and ship
ship records the shipment and advances the order; tracking flows back to the customer.
5. Cancel, if it comes to that
Cancellation releases reservations and reverses inventory effects. Terminal-state guards apply β
a shipped order cannot be cancelled, it has to be returned.
6. Post-purchase
Returns, exchanges, and refunds tie back to the original order and adjust inventory
deterministically. See Returns Workflow.
Reading state
List calls are bounded by a server-side limit policy β default 500, maximum 1000 β so an
unbounded scan isnβt possible. See
API hardening.
Every monetary value crosses as an exact decimal string ("149.99"), never a float. Donβt
parse into a binary float before doing arithmetic.