Why API integrations break down once things get busy

The order sits neatly in the webshop, but there is no trace of it in the ERP. A new customer was created in the CRM and still has no access to the portal two days later. Stock levels on the marketplace are structurally a few hours behind. Anyone who works with connected systems every day recognises these reports instantly.

The error message you find at that point is rarely the cause. It is simply the moment the problem became visible. The real cause almost always sits earlier in the chain: the integration was once built as a piece of technical plumbing between two applications, and by now a chunk of your daily operation runs through it.

You only notice that difference when circumstances change. Volumes double, a supplier adjusts its API, or a message gets sent a second time after a time-out just to be safe. That is when it turns out an integration has to do more than pass data along. It also has to cope with delays, duplicate messages, incomplete records and systems that are temporarily unavailable. Arrange that up front and an outage stays a technical incident. Leave it open and it becomes manual work, backlog and awkward explanations to customers.

So why does an integration break?

An API integration breaks the moment two systems hold different expectations about data, timing or availability. One system assumes a customer number is always included. The other only assigns that number after someone has approved the customer. Or your webshop fires off a message on every change, while the receiving party accepts no more than sixty requests per minute.

Usually nobody is at fault. What is missing are agreements about the exceptions. May an order be processed twice if it is unclear whether the first attempt arrived? What happens to an address that fails validation? What should happen when a supplier's API goes quiet for ten minutes? Without answers to questions like these, the integration stops at the first scenario that deviates from the ideal path.

On top of that, APIs move. External parties change fields, versions, authentication and limits. Sometimes with an announcement months in advance, sometimes with a line in a changelog nobody reads. An integration that ran without a hitch last year can go quiet today without a single change on your side.

The technical causes, one by one

Data that does not line up

Differences between data models are by far the most common cause. Your webshop has one field for product status, while your stock system distinguishes between available, reserved, in transit and blocked. If that translation is not made deliberately, the receiving side gets a value it cannot do anything with.

Mandatory fields are the second classic. A phone number, VAT number or country code is optional in the source system and required in the target system. An integration that checks this before sending holds the message back and states exactly what is missing. If it does not, you build up a pile of rejected messages for someone to sort out by hand later, usually right when things are already busy.

Timing and sequence

Plenty of processes consist of steps that wait on each other. First the customer, then the order, then the invoice. If the order arrives before the customer, it gets rejected because the customer does not exist yet. In a CRM and ERP integration this is one of the most frequent reasons things grind to a halt.

It shows up mainly in integrations running over webhooks or background processes, where messages can overtake each other. Pushing everything through immediately feels fast, but it does not always give the best result. A short queue that guarantees the order of processing is more reliable for this kind of chain. That means seconds or minutes you build in deliberately, not the hours of backlog that pile up when messages quietly sit there unnoticed.

Time-outs, rate limits and short outages

Every external API has limits. Maintenance, a time-out, a cap on requests per minute: it comes with the territory. An integration that immediately resends on every error only makes the problem bigger. The API gets extra traffic at the worst possible moment and starts refusing even more requests.

Retrying harder is not the answer. What does work: resending with increasing intervals, a maximum number of attempts, and a separate place for messages that definitively cannot be processed. That keeps an outage manageable and stops anything from disappearing quietly.

Expired tokens and changed versions

Access to an API usually runs on tokens, keys or OAuth. Tokens expire, permissions get adjusted, security requirements get stricter. If those credentials are hard-coded or nobody owns their upkeep, the integration stops at a random moment. In practice, often at the weekend.

Version management deserves the same attention. A supplier renames a field, removes an endpoint or changes the structure of a response. Contract tests and a fixed routine for reviewing announced changes cost little time and mean you find out before your colleagues do.

Often the problem is not in the code

Technology is only half the story. Integrations also break because it is unclear who is up next when something goes wrong. The software vendor points at the hosting provider, the hosting provider points at whoever built the integration, and they point at the external API. Meanwhile customer service is waiting on data they need to help someone.

That is why an integration needs a functional owner. Someone who knows what data flows through it, what it means for the business when that flow stalls, and when a deviation calls for action. This does not have to be a developer. It does have to be someone who can make the call: can this order wait until tomorrow, does this need fixing right now, or do we rerun the batch later?

Give process changes a fixed place in that same conversation. An extra invoice field, a new order status or one more sales channel looks small. For an integration it often means the validations, translations and error handling all need another look. Involve your technical partner before the change goes live, not on the day the data stops coming through.

What actually makes an integration reliable

It starts with getting the data flow clear. Not just "system A sends orders to system B", but also: which system wins when records conflict, which fields are mandatory, how quickly does something need to be available, and what happens when a step fails? Those are business decisions with technical consequences, not technical details.

Then comes error handling. A message saying "synchronisation failed" helps nobody. This is useful: order 10482 was rejected because the delivery country code is missing, at 09:14, after three attempts. A colleague can act on that, and so can a developer.

Logging on its own is not monitoring. You also want to know when the numbers deviate from normal. If a thousand orders an hour usually run through the integration and suddenly there are twenty, that is a signal, even if not a single error was logged. Those silent failures are exactly the ones that otherwise surface at the end of the day.

For critical processes it pays to hold messages in a queue. If the receiving system goes down, they are kept and processed in a controlled way once it is back. Just make sure double processing is impossible. Duplicate messages genuinely happen, for instance after a time-out where it is unclear whether the first message arrived. The integration then has to recognise it is the same order and ignore the second one.

And test with the messy cases. Not only the perfect test order, but also a Belgian address with a four-digit postcode, a missing customer number, a return, a cancelled payment and a receiving system that drops out halfway through processing. That is the difference between a demo that works and a process that survives a busy Monday.

Repair or rebuild?

Not every broken integration calls for a rebuild. If the setup is sound, the code is still readable and the errors mostly come from changes on the other side, targeted maintenance is enough. Refreshing authentication, adding validation, mapping a field differently: that is days of work, not months.

A rebuild makes more sense once the integration has turned into a collection of workarounds. The signs are fairly recognisable: daily manual corrections, error messages nobody can explain, code nobody dares to touch, and dependencies that only exist in one person's head. At that point, patching costs more over a year than redesigning the process properly.

Do not overlook the environment underneath it. A well-built integration can still slow down if background jobs get too little capacity, the database buckles under peak load, or hosting and application management sit apart from each other. At LJPc development and hosting sit together, so tracking down a cause does not have to travel via three parties.

The best integration is not the one you never hear about. It is the one where you know what data is in transit, who raises the alarm when something deviates, and how recovery works. Then technology is just a tool, instead of a daily source of delay.