Skip to main content
Create a return against a real order line in a fresh local database using @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.1 installed; see SDK installation.

Run the complete example

Save this as returns-demo.mjs:
Success: the script finishes with this output. The completion error is an expected assertion, not a completed return:

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 reaches received. 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.
Last modified on September 20, 2026