BlogDevelopment8 min read

API integration patterns, and the four that stop it breaking

The short answer

Reliable integrations need four things: idempotency so a repeated event does not create a duplicate record, retries with backoff then escalation, a dead-letter store you can replay from, and contract tests so a supplier's breaking change fails CI rather than your accounts team.

API integration patterns, and the four that stop it breaking — illustration

Key takeaways

  • Decide which system owns each record before writing any code.
  • Idempotency is the most commonly omitted practice in integrations we inherit.
  • Alert on silence — a sync that stops is invisible without it.
  • Scheduled reconciliation catches the drift that event-driven sync always accumulates.

Almost every operational problem we are asked to fix turns out to be an integration problem in disguise. The data exists; it is in four systems that have never been introduced, and a person in the middle is doing the joining by hand.

Decide ownership first

Before any code: which system owns the customer, the order, the invoice? Skip this and you build bidirectional sync between two systems that both believe they are authoritative, producing conflicts nobody can adjudicate. It is a governance decision with a technical implementation.

The four practices

Idempotency
The same event delivered twice must not create two orders. Every handler keys on an event id and does nothing the second time. This is the single most common omission in integrations we inherit, and its symptom is duplicate records nobody can explain.
Retries with backoff, then escalation
Third-party systems go down. An integration that gives up after one failure loses data; one that retries forever hides a problem. Retry with increasing delays, then tell a human.
Dead-letter replay
Events that fail every retry land in a store you can inspect and re-run. Without it, an outage at the other end is permanent data loss rather than a delay.
Contract tests
Tests in CI that call the endpoints you depend on and assert their shape. A supplier's breaking change then fails a pipeline instead of surfacing three weeks later in a reconciliation.

The integration that matters most

For most Indian businesses it is leads: every source normalised into one intake, deduplicated on phone number, attributed at the moment of submission, routed to an owner in seconds — and, crucially, the qualification outcome sent back to the ad platforms. Without that return leg you optimise in an open loop forever. The full flow is in CRM integration services.

When a no-code tool is the right answer

Zapier / Make / n8n

  • Low volume and a simple field mapping
  • The failure is annoying rather than expensive
  • Nobody on the team writes code
  • You need it working this week

Build it properly

  • Per-task pricing has started to hurt
  • You need idempotency and replay
  • A silent failure costs real money
  • The logic has outgrown a visual builder

We recommend the left column regularly. The line is volume and consequence, not technical sophistication — the full scope is on API Development & Integrations.

Sources

Questions people also ask

Usually. Older systems often lack a modern API, so the approach is a middleware layer that reads and writes through whatever mechanism exists — a database view, an export, an ODBC connection — and exposes something sane to everything else, without modifying the ERP.

Keep reading