--- title: "Keep retries from creating duplicate business records | R&D COPILOT" lang: en canonical: https://rdcopilot.com/insights/integrations-retries-duplicate-records/ content_version: ada374a322208cad94dfb0482f8c2faef5bb13a042f64fb8b0b84c47df694970 contact: https://rdcopilot.com/contact/ --- [RDC](https://rdcopilot.com/) [Insights](https://rdcopilot.com/insights/)Integrations IntegrationsWorkflow # Keep retries from creating duplicate business records A timeout tells the connector that it did not receive a timely answer. It does not prove that the destination failed to create the order. We design retries around a stable business operation and a recorded outcome, so recovery can continue the intended work without accidentally repeating it. The exact mechanism depends on the destination API and must be checked during scoping. By R&D COPILOT6 October 20265 min read In this guide 1. [Identify the business operation once](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-section-1) 2. [Store outcomes where replay can find them](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-section-2) 3. [Separate safe retry from human investigation](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-section-3) 4. [Keep replay authority controlled](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-section-4) 5. [Test the failure after acceptance](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-section-5) 6. [Scope recovery against the real API contract](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-section-6) [Sources & inspiration](https://rdcopilot.com/insights/integrations-retries-duplicate-records/#guide-sources) ## Identify the business operation once An order number, event identifier and request attempt are different identities. Define which business action should happen once and preserve its identity across attempts. A new network request should not automatically become a new order. If the business intentionally changes the order, record the new operation and its relationship to the earlier one. Use the order-creation intent as the stable unit, with individual attempts recorded beneath it. The operation identity should survive a process restart and queue redelivery. Decide which changes create a new intent: editing an address may be an update to an existing order, while creating a second order is a different action. Keep these decisions in the business contract so retries cannot accidentally stand in for an amendment workflow. ## Store outcomes where replay can find them Where the destination supports idempotency keys, follow its rules for key lifetime, changed parameters and repeated requests. The connector also needs its own record of attempts and outcomes. If no such mechanism exists, consider destination lookup, controlled serialization or reconciliation. Do not describe a client-generated key as a guarantee the destination never promised. Persist the request identity and relevant payload before sending, then record the destination reference when it becomes known. Think through a crash between each of those steps. A local database transaction cannot make an external API call atomic by itself. Depending on the destination contract, the design may need an outbox, destination lookup or a reconciliation process. Explain those guarantees precisely rather than describing the integration as universally exactly-once. ## Separate safe retry from human investigation Some errors establish rejection; others leave the result uncertain. A changed payload on the same operation also requires attention. Display these states distinctly so an operator cannot accidentally force a second creation. Recovery should preserve the original operation context and document why a new action was authorized if investigation shows that it is necessary. Classify errors using what is known about the business outcome. A documented validation response can authorize correction; a dropped connection after submission cannot safely be treated the same way. Limit automated retries and preserve the unresolved state when the result cannot be established. An operator should see prior attempts and the destination lookup result before deciding whether another creation is justified. Avoid a reset button that erases the evidence needed for that decision. ## Keep replay authority controlled The person who can view an error does not automatically need permission to replay a write. Limit recovery controls by business operation and record the operator's decision. Avoid putting credentials or full personal records into idempotency keys and URLs. Retained attempt logs should carry useful identifiers without becoming another uncontrolled copy of customer data. Keys should identify operations without embedding names, account numbers or secrets. If identifiers are logged externally, check whether they expose business relationships through predictable values. Restrict manual replay and require a visible reason for overriding a hold. Separate a developer's ability to investigate from their authority to repeat a commercial operation. The audit record should connect the operator decision to the exact payload and destination action it authorized. ## Test the failure after acceptance The critical test interrupts the connection after the destination accepts the order but before the connector stores the response. Also test duplicate events, concurrent attempts and changed parameters. Count duplicate business records and unresolved outcomes. A green HTTP dashboard is insufficient when two apparently successful attempts created two orders. Build a failure schedule that interrupts the process before sending, after destination acceptance and before local acknowledgment storage. Add simultaneous deliveries of the same event and a repeated key with changed data. Verify both destination records and local outcomes after recovery. Measure unresolved operations separately from duplicates: suppressing every retry can prevent duplicates while silently losing legitimate work. The acceptance evidence needs to show that the intended operation eventually reaches a known result. - Keep one business-operation identity across retries, restarts and queue redelivery instead of generating a new order intent. - Test a crash after destination acceptance but before the connector records its acknowledgment locally. - Check the destination's key lifetime and changed-payload behavior rather than assuming universal idempotency guarantees. - Count unresolved legitimate work separately from duplicates, and preserve evidence before authorizing any manual replay. ## Scope recovery against the real API contract We can review an existing connector or build a new path with operation identity, outcome storage and an operator recovery view. Bring the destination documentation and a record of current failure cases. The quote should identify any limitations that need business procedures, such as a destination that cannot search reliably for an earlier accepted request. We can review the current connector's operation model and test its recovery against the actual API. A targeted repair may add durable identities and outcome reconciliation without replacing the full platform. Where destination capabilities are insufficient, the proposal should state the manual control required for uncertain cases. Include batch behavior and historical data cleanup separately; preventing future duplicates does not automatically identify or reverse duplicates already present. Inside the product ## Integrations [![Invoice workflow with validation rules, approval and handoff stages.](https://integrations.rdcopilot.com/product-demos/integrations/gallery-overview-en.png)View full size](https://integrations.rdcopilot.com/product-demos/integrations/gallery-overview-en.png) Invoice workflow with validation rules, approval and handoff stages. [![Completed workflow with finance approval and the prepared accounting handoff.](https://integrations.rdcopilot.com/product-demos/integrations/gallery-detail-en.png)View full size](https://integrations.rdcopilot.com/product-demos/integrations/gallery-detail-en.png) Completed workflow with finance approval and the prepared accounting handoff. Swipe or use the arrows to explore. Image 1 of 2 Follow the references ## Sources & inspiration ### [AntWMS](https://devpost.com/software/antwms) Devpost project by Mohammad Rafaquat Alam Metadata-aware warehouse decisions. This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis. - [Stripe: idempotent requests](https://docs.stripe.com/api/idempotent_requests) - [Stripe: receive webhook events](https://docs.stripe.com/webhooks) Put the guide to work ## Start with your workflow. Tell us what your team needs to do, which systems are involved and where the current process slows down. [Discuss your project](https://rdcopilot.com/contact/?service=workflow-automation) [Explore Integrations](https://integrations.rdcopilot.com/en/products/integrations/) Integrations ## Keep exploring. [All guides](https://rdcopilot.com/insights/) Decision guide ### [Choose the first API integration by the manual work it removes](https://rdcopilot.com/insights/integrations-first-manual-handoff/) Choose a first API integration from a real manual handoff, with clear data ownership, destination results, exception handling and a buildable project brief. [Read guide](https://rdcopilot.com/insights/integrations-first-manual-handoff/) How-to guide ### [Who notices when an integration stops halfway?](https://rdcopilot.com/insights/integrations-monitoring-recovery/) Monitor integrations through the business completion signal, queue age and missing activity, with owned exceptions and tested recovery for stranded records. [Read guide](https://rdcopilot.com/insights/integrations-monitoring-recovery/)