Integrations
Why API Integrations Become Expensive and How to Design Them Properly
Published 6 October 2026 by 7Webs
On a whiteboard, an integration is an arrow between two boxes. The estimate reflects the arrow. The cost comes from everything the arrow leaves out.
Integration projects rarely overrun because the API calls are hard. They overrun because of what happens around the calls: failures, duplicates, disagreements between systems and changes nobody announced.
Where the cost comes from
1. Nobody decided which system is right
When the CRM says a customer’s email is one thing and the billing system says another, which wins? If the answer is “whichever synced last”, you will get corrupted data and a slow, expensive hunt for the cause.
2. The happy path was the only path built
The demo works because every call succeeds. In production, APIs time out, rate-limit, return partial results and go down for maintenance. An integration without retry logic silently drops data during each of those moments.
3. Operations are not safe to repeat
A request times out. Did it succeed? If you retry and it had, you now have two orders, two invoices or two payments. Without idempotency, every retry is a gamble.
4. Failures are invisible
The integration stops at 2 am on a Tuesday. Nobody notices until a customer complains on Friday. By then there are three days of records to reconcile by hand.
5. The other side changes
Third-party APIs add fields, deprecate versions and change behaviour. An integration that assumed the response would never change breaks without a single line of your code being touched.
6. The data does not mean the same thing
One system’s “customer” is a company, the other’s is a person. One stores prices with tax, the other without. These mismatches are found late, and they change the scope.
How to design it properly
Assign an owner to every field. For each piece of data, write down the one system that is the source of truth. Others receive updates and do not originate them. This single document prevents most sync bugs.
Put a queue in the middle. Do not call the other system directly from a user’s request. Record the event, then process it in the background. If the other side is down, events wait and nothing is lost.
Make every write idempotent. Give each operation a unique key, so that sending it twice has the same effect as sending it once. Most serious APIs, Stripe among them, support this directly.
Retry with backoff, then park. Retry failed calls at growing intervals. After several attempts, move the event to a dead-letter queue where a person can inspect and replay it.
Verify incoming webhooks. Check signatures, respond quickly, and process afterwards. Expect webhooks to arrive twice and out of order.
Log and alert. Record every exchange with enough detail to replay it. Alert a human when failures pass a threshold, so you hear about a problem before your customers do.
Reconcile on a schedule. Run a regular job that compares the two systems and reports differences. It catches whatever the event flow missed.
Isolate the third party. Keep all knowledge of the external API in one module. When it changes, you change one place.
What this costs
Designing an integration this way adds effort at the start, typically a modest fraction of the build. Skipping it moves that cost to later, multiplied, and paid in staff time, bad data and lost customer trust.
When you compare quotes for integration work, ask each supplier what happens when the other system is unavailable for an hour. The answer tells you which quote is actually cheaper.