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.
The Replay Room
Follow one intended order as a request is created, repeated and changed. Watch the original order identity stay visible throughout the retry and conflict scenes.
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.
Replay the captured requests
Select a step to inspect what was sent and returned. This is a replay of the recorded sandbox evidence; these controls do not call the API or create orders.
Request
Response
Original 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
“Your agent hits retry. Is that a second order? Start with one approved order. Give that operation one stable key. The first request creates an order. Two hundred and one. Keep that order ID. The network is uncertain. Send the same body and key again. Same order. Change the quantity. Reuse the key. Four hundred and nine: conflict. The change is rejected. This is a real sandbox test. Created. Replayed. Conflict. One order identity. One key per intended order. Make retries boring. Build with OrderCore.”
The Replay Room follows a paper ticket through an illustrated order system. Two new ComfyUI Wan 2.2 motion sequences frame the story; precise animated diagrams show creation, replay and conflict. The generated sequences are 576 × 1024, interpolated and upscaled within the final 1080 × 1920 edit. The diagrams and text are rendered at the final resolution. Narration, timed captions and an original synthesized soundtrack complete the 44-second film.
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.