How it works / Real API results
One order, three requests: watch OrderCore handle retries
An agent sends an order request. The connection times out. Should it send the request again? Here is what happens when retries keep the same identity.
A retry returns the same order ID. Reusing that key for changed order data returns a conflict. Give a new intended order a new key.
Where OrderCore fits
Your agent helps a buyer select products. Your application checks the buyer's approved items and quantities, then calls the commerce backend. OrderCore provides catalog, inventory, pricing, checkout and order APIs. This demonstration focuses on one specific step: creating a durable order safely when a request is repeated.
- Choose and approveRead the catalog and validate the buyer's intended purchase in your application.
- Create the orderSend the approved order to OrderCore with a stable idempotency key.
- Retry predictablyIf the outcome is uncertain, repeat the same body and key instead of creating a new order identity.
The exact three-request test
We used POST /v1/orders in a fresh isolated write sandbox. The first two calls had identical bodies and the same Idempotency-Key. For the third call, we changed the quantity from one to two while keeping the key.
| Request | HTTP result | What it means |
|---|---|---|
| First request, quantity 1 | 201 Created | Order created with status pending. |
| Same key, same body | 200 OK | The same order ID is returned. |
| Same key, quantity 2 | 409 Conflict | The changed payload is rejected. |
Both successful calls returned order ID bf449590-4c05-4191-a1cd-9d0b502c2bb2. The guarantee shown here is the same order identity; it is not a claim that every response field is byte-for-byte identical.
Inspect the captured request and responses (JSON). The evidence contains no API credential.
What your integration should do
- Create and persist one key when your application accepts a new intended order.
- Reuse that key and the original body when retrying that operation after an uncertain result.
- Do not generate a new key for each network attempt: that would describe separate operations.
- On a 409, reconcile the original operation and the changed request. Do not silently create a different order to bypass the conflict.
- Use a new key when the buyer explicitly approves a genuinely new order.
What this video proves
It demonstrates order creation, replay and payload-conflict handling in an isolated sandbox. The order remains pending. It does not demonstrate a card charge, delivery or a complete production purchase. Payment and fulfillment require their own integration and verification.
Video transcript
“One request. One order. Let's send it again. The first request returns two hundred and one. Order created. Repeat the same key and body. Two hundred. Same order ID. Change the body but reuse that key, and OrderCore returns a conflict. Keep one key per intended order. Build reliable retries with OrderCore.”
The illustrative motion was generated in ComfyUI using Wan 2.2, then combined with captured API results, narration and captions. Generated footage is 432 × 768, interpolated and upscaled for the final 1080 × 1920 video.
Try the flow yourself.
Start with the sandbox walkthrough to inspect the API. Or run the offline demo to explore the checkout flow without credentials.