Before and after · API reliability

When a POST times out, did the write fail?

A lost response leaves the client unsure. Retrying the same write can create a second order. Compare the two paths.

Without a key

Client sends POST orders; order 42 is created but the reply is lost. A retry creates order 43. — The first write worked; its response did not arrive. Open the image to see full size.

With the same key

Client retries POST orders using the same idempotency key K7; the API returns the result for order 42. — Both attempts map to one result when the API supports and honors the key. Open the image to see full size.

The detail that matters

The key must identify the same intended operation on both attempts. This is an example of an API that supports idempotency keys; a random retry header does not make every endpoint safe.

View and edit a copy

The editable drawing is carried in the link. It is not saved to a cloud account. These example marks were composed with an agent in Drawbly.

Reference: Stripe API: idempotent requests. Stripe documents reusing a key for retries and returning the saved result.

Next: read a slow trace in three passes →

When a POST times out, did the write fail?

The detail that matters

Try the idea on your own canvas.