API development and integrations: what brands keep getting wrong when connecting systems

Every new system a brand adds raises the same question: how do we make this talk to everything else? CRM, CMS, payment provider, loyalty platform, marketing automation. At some point there are ten systems and twenty point-to-point connections holding them together. Then something breaks and nobody knows where to start looking.

At Livewall, we build web applications and digital platforms where integrations aren't an afterthought. They're part of the design. And we see the same pattern in almost every project that starts with legacy connections: the technology isn't the problem. The architecture is.

The most common mistake: point-to-point connections

A brand integrates its CRM with its email platform. Direct, fast, done. Then a loyalty platform comes along, so they connect that to the CRM too. Then an app. Then a data platform. Before long every system is directly connected to every other system and the entire infrastructure is a web of dependencies.

This is the point-to-point trap. Each individual connection makes sense on its own. Together they create a maintenance nightmare. One API change at a vendor cascades through the whole landscape. Nobody dares to touch anything.

The solution isn't complicated: build a central integration layer, or use an API gateway, that acts as the single contact point for external systems. Systems speak to the gateway, not to each other.

No versioning on your APIs

The second mistake is missing versioning. Teams build an API, it works, they move on. Then another team wants to change something. The endpoint shifts. Everything depending on it breaks.

Good API design assumes things will change. Versioning isn't administrative overhead, it's a promise to the systems that depend on your API. /v1/orders keeps working even when /v2/orders returns a different data format. Consumers choose when they migrate.

We see this most often with internal APIs that were once built as a temporary fix. No documentation, no versioning, no contract. And then the system is still in production six years later and nobody touches it out of fear.

Error handling as an afterthought

The third mistake is treating error handling as something to add at the end. An API call fails. What happens? If the response is just a silent timeout or a generic 500 error, the receiving side knows nothing. Was it a temporary problem? A data validation error? An authorisation issue?

Good APIs have explicit error codes that carry meaning. They distinguish 4xx errors (something on your end) from 5xx errors (something on ours). They return readable error messages that tell developers something useful. And they log on both sides.

Retry logic also belongs in the design, not the implementation. Do you know which operations are idempotent? Can you send the same call twice without creating duplicate payments or duplicate records? If the answer is 'not sure', there's work to do.

Authentication as an afterthought

API security is the fourth area where things go wrong. OAuth 2.0, API keys, JWT tokens: the right choice depends on context. But what we regularly see is authentication being added after the API is already built, meaning the implementation doesn't fit the design.

An API used internally has different security requirements from one serving external partners or consumer apps. Service-to-service communication works differently from user authentication. Scopes and permissions need to be thought through from the start, not applied as a layer of varnish on a working system.

Rate limiting belongs here too. Without it, your API is vulnerable to abuse and to the well-meaning developer who accidentally writes a loop making a thousand calls per second.

What good API architecture actually looks like

Good APIs have a single responsibility. They do one thing well and return it in a consistent format. No endpoints that perform ten different operations depending on query parameters. No response objects that grow until nobody knows which fields are always present.

Good APIs have a clear contract. OpenAPI or a comparable schema that describes what each endpoint accepts, what it returns, and what errors look like. Not as documentation written after the fact, but as the starting point for implementation. Contract-first development prevents surprises on both sides.

And good APIs grow in a controlled way. With the KLM scalable growth approach, serving 50+ markets was only possible because the underlying system was built on clean integrations with clear responsibilities. When a new market was added, the integration followed a pattern that already worked. No manual intervention per market required.

Integrations compound over time

The real problem with poor API architecture is that it compounds. One badly integrated system is manageable. Five of them create exponentially more risk and maintenance cost.

Every integration you add without a clear contract, without error handling, without versioning, is an investment in future problems. Three years later there are ten of those connections and every platform migration costs twice as much as it should, because nobody knows exactly what depends on what.

At Livewall we use a simple test: if you can't describe an integration in one sentence ("system A sends user data to system B via the orders API when a purchase is confirmed"), the scope is probably too broad or the responsibility split isn't clear.

The question to ask before you build isn't "how do I connect this" but "what is the minimum, most stable connection that achieves this goal and will still be understandable in three years".

Digital strategy done well answers that question before a single line of integration code is written.