Skip to main content
Start with one customer, one warranty, and two claims. Approve and complete one claim with a replacement resolution; deny the other and verify that it cannot be approved afterward. This complete example uses @stateset/embedded 1.35.1 in a temporary local database. No API key, store connection, or support platform is required.
A warranty records coverage; a claim records an issue and its decision. Completing a claim with replacement records that resolution. It does not create a replacement order, buy a shipping label, issue a refund, or notify the customer.

Prerequisites

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

Run the complete example

Save this as warranties-demo.mjs:
Success: all assertions pass and the output is:

Understand coverage dates and identities

In this version, durationMonths: 12 produces 360 days, not a calendar-year anniversary. The published Node CreateWarrantyInput does not expose explicit start or end dates, and this example starts coverage at creation. Do not claim that it automatically starts at purchase, fulfillment, or delivery. If your policy requires a particular start event or calendar-month calculation, choose an interface that supports that policy and verify the stored dates. The Node WarrantyOutput does not expose serialNumber, even though creation accepts it. The WarrantyClaimOutput includes status and resolution but not the full coverage decision or denial-reason history. Retain the policy version, evidence, decision maker, and explanation in the system that owns the review.

Know what can be independently verified

The example reads the warranty back with warranties.get(warranty.id). Claim assertions use the responses from claim mutations: the published Node Warranties class has no getClaim or listClaims method. warranties.get(claim.id) is not a claim lookup. Before building recovery or an agent workflow, choose a supported claim-reading interface in your deployment. The commerce API directory describes the separate HTTP surface; it requires a deployed service and its own request/authentication contract. Do not assume that installing this local package exposes an HTTP server. The rejected approval demonstrates a conflict with a denied claim. It does not provide an independent claim read-back. Do not treat any CONFLICT response as proof that the requested action succeeded.

Connect the decision to a real outcome

Approval and fulfillment are separate steps. Before completing a production claim, verify the outcome required by your process and retain its related record IDs. Use the orders quickstart, shipping guide, and payment guide to understand those separate records. None of these downstream operations is performed by the claim program above. A return is also a separate record; link it explicitly if your process requires the original goods back.

Handle retries and partial failures

The published warranty and claim creation signatures have no idempotency-key parameter. Map your external coverage or support-case identity to the returned warranty and claim IDs. After an uncertain create response, reconcile the original request before creating another record. A timeout during replacement fulfillment must not cause another replacement order on every retry. Track the claim decision, downstream operation, and completion evidence separately. If your chosen binding cannot read a claim after interruption, resolve that read capability before allowing unattended recovery; do not guess a getClaim method or replay writes to discover state. See error handling and retries and the integration test plan for recovery checks.

Give an agent a claim task

For a review task, provide the coverage and claim IDs, applicable policy, relevant purchase or fulfillment evidence, and an actual claim-reading tool. Ask the agent to distinguish observed facts from missing evidence and propose a decision without changing state. For an authorized write, specify the permitted decision, limits, and required evidence. Claim approval alone does not authorize a refund, replacement order, shipping label, or customer message. Discover installed tool schemas and enforce the configured permission policy before any mutation. See the agent operating procedure. A completion report should list the claim decision and downstream outcome separately, with record IDs and whether each result came from a mutation response or an independent read.

Troubleshooting

Next steps

Last modified on September 20, 2026