@stateset/embedded 1.35.1. This example verifies creation, idempotent replay, approval,
tracking and receipt. It also checks that completion is refused while item dispositions are missing.
The demonstration does not contact a carrier, issue a shipping label, or send money through a
payment provider. Shipping and receipt are simulated by updating local records.
Prerequisites
- Node.js 20.20.0+ and npm 10+.
- A project with
@stateset/embedded@1.35.1installed; see SDK installation.
Run the complete example
Save this asreturns-demo.mjs:
Understand the request
A SKU identifies a catalog item, while
orderItemId identifies the purchased line. Use the
line ID from the original order, not a product ID or an invented placeholder.
Follow the lifecycle
The code above reachesreceived. The returns workflow reference
lists the methods and explains the additional completion requirement.
What a disposition means
A disposition records what should happen to a received item, such as restocking, quarantine, refurbishment, scrapping or return to vendor. A receipt status alone does not record that decision. In the published Node binding 1.35.1,returns.complete(id) enforces the disposition check,
but the Returns class does not expose a setter for item dispositions. Plan that step in an
integration that supports it before attempting a production end-to-end return workflow. Repeating
complete with unchanged data will fail again. The binding also does not expose the completion
write-off option named in the underlying error.
This tutorial intentionally leaves the return at
received. A complete financial workflow
must also track the refund in the payment system and verify its result. An RMA state change
is not evidence of a payment-provider refund.Handle retries and alternate paths
The example submits the same request and key twice and checks that only one return exists. Keep that key with the operation. Generate a different key when you intend a different return, not whenever a request times out. Approval, rejection and cancellation are separate decisions. Use the method appropriate to the current state; do not mark a failed operation as cancelled merely to hide the error. Read the record back before retrying a transition whose outcome is unclear. For a policy-controlled flow, follow verified refund decisions before connecting a tool that performs a refund.Troubleshooting
Next steps
For coverage decisions and replacement outcomes, use the separate warranty claims quickstart.Returns workflow reference
Review transition methods, lookup methods and completion requirements.
Order lifecycle
Understand the order that the return refers to.
Verify a refund decision
Add a policy decision before a consequential action.
Get help
Share the binding version, current state and redacted error.