# Retry a failed sync without creating the same record twice

**URL:** <https://community.autommate.com/t/retry-a-failed-sync-without-creating-the-same-record-twice/226>\
**Category:** Use Case Hub\
**Created:** [October 16, 2026, 11:46am UTC](https://community.autommate.com/t/retry-a-failed-sync-without-creating-the-same-record-twice/226 "2026-10-16T11:46:20Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Caglayan](https://avatars.discourse-cdn.com/v4/letter/c/f9ae1b/32.png) [@Caglayan](https://community.autommate.com/u/Caglayan)\
**Post date:** [October 16, 2026, 11:46am UTC](https://community.autommate.com/t/retry-a-failed-sync-without-creating-the-same-record-twice/226/1 "2026-10-16T11:46:20Z")

</div>

_Autom Mate Team · Practical example_

A create request times out. Did the destination reject it, or did it create the record and lose the response? Retrying immediately can create a duplicate.

Design the retry around the business operation, not just the error message.

1. **Give the operation a stable reference.** Use the source record ID and intended operation. Keep the same reference across retries.
2. **Store the destination result.** When a create succeeds, retain its returned ID and link it to the source.
3. **Check after an uncertain failure.** Query the destination for that reference before another create. Use its idempotency mechanism where the API supports one.
4. **Retry only the appropriate failures.** Use bounded retries for temporary failures. Missing required fields need correction, not repeated submission.
5. **Verify the final record.** Confirm the destination ID and expected fields. If the outcome remains uncertain, route it for review.

**Example:** a customer-record create times out, but a lookup finds the new record. Store its ID and continue instead of creating again.

**Done when:** a repeated operation leaves one correct destination record.

Autom Mate’s [error-handling guide](https://docs.autommate.com/userguide/operate-and-troubleshoot/handle-errors-and-debug-a-flow) explains retry behaviour; duplicate protection still belongs in your flow design.

Which system gives you the most ambiguous timeout responses?