How common are duplicate-record bugs in off-the-shelf integration tools (like Zapier)?

More common than most users realize, because many pre-built connectors don't implement duplicate prevention by default — it depends on the specific integration's design, not just the platform. Always test failure scenarios, not just the happy path, regardless of the tool.

What's a reasonable retry count for a failed send?

Three to five retries with increasing delay between attempts is a common, sane default for most business integrations — enough to survive a brief outage without hammering a struggling system or creating excessive duplicate risk.

How often should reconciliation checks run?

Weekly for high-volume integrations (frequent invoicing, high transaction count); monthly is often sufficient for lower-volume connections. The right frequency depends on how quickly a discrepancy would become expensive to unwind if it went unnoticed.

Can I add duplicate prevention to an integration that's already live and causing problems?

Usually yes, though it requires reviewing the existing data for past duplicates first, then adding the identifier logic going forward — worth doing as soon as the problem is identified rather than living with ongoing risk.

Is this a bigger risk with custom-built integrations or off-the-shelf connector tools?

Either can have the problem — the risk comes from whether duplicate prevention and retry handling were explicitly designed in, not from whether the integration is custom or off-the-shelf. Always verify explicitly rather than assuming either type handles it automatically.

App DevMar 10, 2026

The 'Simple Integration' That Sends the Same Invoice Twice

Most "simple integrations" that connect your billing tool to your CRM or job-management system will send a duplicate invoice at some point, unless someone explicitly built in duplicate prevention and a retry policy — not because the integration is badly built, but because retries, network hiccups, and reconciliation are the actual hard part of any integration, and they're invisible until they fail.

Why Do Integrations That "Just Connect Two Tools" Go Wrong?

The sales pitch for an integration is often "it just sends data from A to B." What that description leaves out: what happens when the send fails partway through? What happens if it succeeds but the confirmation response gets lost? Both of those are common, boring, everyday network events — and without explicit handling, both can result in the same invoice, job, or record getting created twice.

What Is Duplicate Prevention, and How Does It Actually Work?

Duplicate prevention means every record created by an integration carries a unique identifier tied to the original action, so if the same action gets sent twice — because of a retry, a timeout, a double-click — the receiving system recognizes the duplicate and discards it instead of creating a second record. Without this identifier, the receiving system has no way to tell "this is the same invoice sent again" from "this is a genuinely new invoice."

What Does a Retry Policy Actually Need to Specify?

Question	Why It Matters
How many times will it retry a failed send?	Unlimited retries can create many duplicates; zero retries can silently drop real data
How long between retries?	Too fast can overwhelm a temporarily struggling system; too slow delays real invoices
What happens after all retries fail?	Should alert a person, not just silently give up

What Is Reconciliation, and Why Does It Matter Separately From Prevention?

Even with good duplicate prevention and a sane retry policy, integrations should be periodically reconciled — a scheduled check comparing record counts and totals between the two connected systems, catching any drift before it compounds. Reconciliation is the safety net for whatever prevention and retries didn't catch, and skipping it means small discrepancies can go unnoticed for months.

What's the Owner-Level Acceptance Checklist Before You Trust an Integration?

Before considering any integration "done": has someone deliberately tested what happens on a failed send (not just a successful one)? Is there a unique identifier preventing duplicate records? Is there an alert if the retry policy exhausts without success? Is there a scheduled reconciliation check, even monthly? If any answer is no, the integration works today but isn't actually finished. Our custom platform work treats this checklist as part of the build, not an optional add-on.

How Do You Catch This Before It Costs You a Real Customer Relationship?

Ask whoever built or sold you the integration these exact questions before go-live, in writing. A vendor who can answer clearly has actually thought about failure modes. A vendor who says "it just works" hasn't, and you'll find out the hard way — usually the first time a customer calls confused about a duplicate charge.