Handle version conflicts and safe retries
Avoid overwriting newer work or repeating an operation after an interrupted response.
- A backend integration that persists request identity until outcomes are known.
Step-by-step walkthrough
- 01
Read the resource’s current version immediately before preparing a write. Include the operation’s expected_version and any additional required version fields.
- 02
Generate a UUID Idempotency-Key for the intended write. Retain that key with the exact request body until the result is known.
- 03
After a connection interruption, retry the identical request with the same key. Do not change the payload while retaining the original key.
- 04
On a 409 conflict, fetch current state and reconcile the newer values. Once you decide on a changed operation, use fresh versions and a new request key.
- 05
Handle a 404 after reassignment as a possible visibility change. Have an authorized manager verify the outcome rather than repeatedly trying the same inaccessible request.
Expected result
Retries preserve intent and conflicts are reconciled against fresh state.
Important details
A retry is still checked against current access. Rate limiting and visibility checks apply even when your integration previously read the record.
Need help with this workflow? Contact the team and include this guide’s title.