System integration

• Outages

  The other side goes away, and your promises still hold.

• Duplicates

  Running twice has to be safe, because eventually it happens.

• Disagreement

  Two systems, one truth, and a rule for which one wins.

• Traceability

  Six hours later, somebody has to see what happened.

The other side goes away

Every external system you depend on will be unavailable at some point, usually without warning and usually during your busiest hour. The question is whether that becomes your outage. It does if your checkout calls their API synchronously and waits. It does not if the call is queued, retried with backoff, and the customer sees a confirmed order while the system works through the backlog behind them.

That decision is made on the first day and is expensive to change later, because by then the whole application assumes the call is instant.

The same thing happens twice

Networks time out after the other side has already done the work. A retry then creates a second order, a second charge, or a second shipment. Idempotency is how you stop that: every operation carries a key, the receiving side records what it has already processed, and a repeat is recognised rather than re-executed.

This has to be designed in. Adding it during an incident, while duplicate invoices are going out, is the worst possible time to be reasoning about it for the first time.

Two systems disagree about what is true

Your ERP says there are four in stock, the storefront says six, and both are technically correct because they last spoke forty minutes ago. Someone has to decide which system owns that number, whether the other one is allowed to make decisions from a stale copy, and what happens when they diverge.

We make that ownership explicit for every field that matters. It is usually the single most useful hour of an integration project, and it is almost always the hour nobody scheduled.

Nobody can tell what happened

Six hours after a failure, somebody has to explain why a customer was charged twice. If the integration logged nothing beyond “error”, that explanation does not exist. We log the payload, the decision and the outcome for anything that touches money or stock, with enough detail to reconstruct the sequence and not so much that you are storing card numbers.

We have built a significant amount of WhatsApp Business API work, including our own product wagate.app, so this is a case where the operational realities are ones we live with rather than ones we read about.

The API itself is straightforward. The parts that catch people are template approval and how long it takes, the twenty four hour customer service window and what you are allowed to send outside it, number and quality rating management, and webhook delivery that is at-least-once rather than exactly-once. A WhatsApp integration that ignores the last point will eventually send a customer the same message twice.

We start by mapping what actually exists rather than what the documentation says exists. That usually means reading the code or watching the traffic, because the gap between the two is where the surprises live.

Then we agree the contract: what data moves, in which direction, who owns each field, what the system does when the other side is unavailable, and what a human needs to be told when automatic recovery has run out of options. That document is the deliverable of discovery, and it is written so you could hand it to another firm.

We build behind a queue by default, with a dead letter path that a person can actually work through, because an integration that silently drops failures is worse than one that visibly breaks.

A single well documented integration, for example a storefront to an ERP for orders and stock, is typically three to six weeks. A multi system programme, where four or five things have to agree with each other, runs three to nine months and is best done one connection at a time with each in production before the next starts.

The number moves on how good the other side’s API is, not on how many fields you want. An excellent API with fifty fields is faster than a bad one with five.

Integration work usually sits alongside a custom platform, and for retail clients it is most often the connection between e-commerce infrastructure and the systems behind it. Where the integration feeds an assistant or an automation, see AI development.

Tell us what needs connecting