API gateway or direct integration: which one fits?

A webshop pulling stock levels from an ERP. A customer portal showing data from the CRM. An app handling payments. As long as everything runs, nobody gives it a second thought. That changes the day one of those systems gets replaced or drops offline for an hour.

The choice between an API gateway and a direct integration is usually presented as a technical question. It only partly is. What matters more is what happens when a vendor changes its API, when a fifth application joins the party, or when someone has to work out at three in the morning why orders are not coming through.

A direct integration is often up and running within a few days. A gateway costs more design time up front. That makes the first option cheaper at the start, but not automatically cheaper five years in. Which route suits you depends on your landscape, your risks and what you intend to do over the next few years.

What is a direct integration?

With a direct integration, system A talks straight to system B. Your web application asks the ERP for an order status. Your CRM pushes new customer records into the marketing platform. Everything needed sits inside that one connection: the authentication logic, the field mapping, the error handling and the exact call the other party expects.

There is nothing wrong with that. For a clearly bounded integration it is often the sensible choice. An internal system that syncs product data with a single supplier once a night does not need an extra layer. The data flow is predictable, the interfaces are stable and there are barely any dependencies. Adding infrastructure would mainly add maintenance.

It gets different as soon as the same source has several consumers. If your ERP is wired directly to the webshop, the warehouse, a B2B portal and a mobile app, all four of them know the technical details of that ERP. Change the login method or the structure of a field and you are editing in four places and testing in four places. By the fourth one you usually discover that nobody remembers who built that connection in the first place.

When a direct integration works fine

Small in scope, one clear purpose, few expected changes and a handful of systems: then there is no reason to make it more complicated. And when real time is not business critical, a simple nightly sync can turn out more reliable than an architecture nobody fully understands.

There is one condition: ownership has to be settled. Someone needs to watch whether the connection still runs, renew certificates in time, assess announced API changes and pick up errors. A connection that gets no attention after go live is not a solution. It is a problem on a delay.

What does an API gateway do?

A gateway sits between your applications and the systems behind them. Instead of every application reaching into the ERP, CRM or payment platform itself, it talks to a single point of access. That point forwards requests, checks who is allowed to do what, and serves data in the shape the consumer expects.

The effect of that is very concrete. Your customer portal does not need to know which system holds an invoice. It asks for invoice data and gets it. If you later move to a different finance package, the interface for that portal stays the same in most cases. The rebuild happens behind the gateway, in one place, where you can test it before anyone notices a thing.

On top of that you can handle authentication centrally, throttle traffic, bring logging together and let two versions of an API run side by side for a while. That last one is worth a lot once external partners are hooked up to your API, because you cannot force everybody to switch over on the same day.

Meanwhile, a gateway solves nothing by itself. Here too you decide what happens on time outs, what you cache, who gets which permissions and what should raise an alert. A badly designed gateway is simply a new bottleneck, made worse by the fact that all your traffic runs through it. The gain is in deliberately centralising where that pays off, not in shoving everything behind one layer because it looks tidier on an architecture diagram.

What the trade-off is really about

The question is not which approach is more modern. The question is where you expect change, growth or risk. A direct integration is optimised for speed and simplicity right now. A gateway is optimised for control once the landscape gets bigger and messier. Both can be the right answer, they just belong to different situations.

How stable is what sits behind it?

Is a new CRM, ERP or PIM on the roadmap? Do you work with vendors that adjust their API a few times a year? Then a gateway keeps you from migrating every consuming application separately. You keep your own processes separate from the quirks of one specific package.

If the system behind it has been the same for years and replacement is not on the agenda, a direct integration is the level headed choice. Do not build an abstraction layer for a problem that will probably never show up.

How many consumers are coming?

One application talking to one external service does not call for a gateway. The moment several websites, apps, internal tools, dealers or partners need access, that flips. You do not want to track separate keys, permissions and exceptions per application in a spreadsheet only one colleague still understands.

This counts double for organisations growing through acquisitions or new sales channels. What is a standalone B2B portal today may be part of a wider platform in two years. A gateway then gives you a fixed way to add systems without prising open the applications you already have.

Security and continuity

A direct connection can be secure, provided it is set up properly. But with every connection you add, the odds grow that keys, permissions and security rules end up scattered across places nobody checks anymore. With a gateway you arrange access control, token management and rate limits in one place, and you see in one overview who is coming in where.

Continuity weighs at least as heavily. What should happen when an external API takes ten seconds to answer? Does your whole webshop wait, or do you show a cached value for a moment? Should an order fail immediately, or can it sit in a queue until the service is reachable again? Those are calls you have to make whichever route you take. A gateway just makes it easier to apply them consistently instead of reinventing them per connection.

Speed and cost

An extra layer costs extra processing. For time critical use, such as certain transactions or talking to machines on a production line, you need to measure whether a gateway stays inside your response budget. Sometimes the answer is no and a direct, well secured connection is technically the better call. Measuring helps more than assuming here, because gateway overhead is often smaller than people expect and the network route underneath it matters far more.

At the same time, look beyond milliseconds. The biggest cost is rarely infrastructure. It sits in incidents, duplicated work and changes you have to coordinate with three suppliers. If an outage only becomes clear after four hours because logging is spread across four systems, a well managed gateway has long since paid for itself.

Choose per data flow, not from a principle

The most common mistake is picking a single principle for every integration. A hybrid setup makes sense more often: a simple internal sync runs directly, while customer facing APIs and partner integrations go through the gateway.

So start by mapping your data flows. Which data is business critical? Which processes genuinely need to be real time and which only look that way? Where do personal data or payments travel? Which systems might change within two years? And who gets the call when a connection stalls?

With those answers on paper, the choice per flow is usually no longer hard. Sometimes it is a direct REST connection with solid monitoring. Sometimes a gateway with versioning and central authorisation. And sometimes asynchronous processing with a queue is the right answer, because your process cannot grind to a halt over an external party that is briefly unreachable.

Keep your integrations out of black box territory

Which architecture you pick matters less than how you run it. Write down which systems exchange data, which source leads for which field, what happens on errors and who has access. Set up alerts that fire before the first customer calls. That sounds dull, but it is the difference between an annoying half hour and a day of firefighting.

Also test changes outside production first, every time. An update to an external API, a replaced certificate or an adjusted firewall rule can break your connection without a single line changing in your own software. With a test environment, clear logging and one fixed point of contact, surprises like that stay manageable.

So for organisations that depend on their digital processes, the best choice is rarely the architecture that looks nicest on paper. It is the one that matches the impact on your business and that you can still manage, adjust and repair quickly two years from now. That is where LJPc starts as well: not with an off the shelf solution, but with the question of where your processes really cannot afford to stutter.