What a reliable integration actually requires

"Just connect X to Y" sounds like a small request, and it's one of the most underestimated kinds of work in software. The connection itself — call an API, map some fields, write the result — is usually an afternoon of work. What actually takes the time is everything that happens when the connection doesn't behave.

Here's what I mean, concretely.

Webhooks arrive more than once

Almost every webhook provider tells you, somewhere in their docs, that delivery is "at least once" — not exactly once. Networks time out, retries fire, and your endpoint receives the same event twice. If "order paid" triggers an email or a stock deduction, and you don't guard against duplicates, you'll eventually double-charge, double-email, or double-deduct something. The fix isn't complicated — track processed event IDs, make the handler idempotent — but it has to be there from day one, not added after the first duplicate shows up in production.

The other system will go down while yours is running

Syncing inventory between a webshop and a planning tool means one of those two services will, at some point, be unreachable while the other is mid-request. What happens then? If the answer is "the sync silently fails and nobody notices for three days," that's not a hypothetical — it's the default behavior of code that only handles the happy path. A reliable integration needs a retry strategy, a dead-letter path for things that keep failing, and — critically — a way for a human to find out something's wrong before a customer does.

Field mapping breaks quietly

Two systems rarely agree on what a "customer" or an "order" looks like. One has a single name field, the other splits first/last. One stores prices in cents, the other in decimal euros. These mismatches don't throw errors — they just produce wrong data that looks plausible until someone notices the totals are off. Good integration work spends real time on the mapping layer, not just the transport layer.

What this means practically

A realistic estimate for an integration project was never for "the call to the API." It's for: idempotent handling, retry and backoff logic, field-mapping validation, and monitoring that tells you when something's actually broken instead of failing silently. That's also why "just use Zapier" is sometimes the right answer and sometimes isn't — off-the-shelf automation tools are fine until the failure modes above start costing real money, at which point custom, properly guarded code is worth the difference.

Have two systems that need to talk to each other reliably, not just eventually? Let's talk about what that actually takes.