From legacy connections to an API-first integration platform

Situation

A manufacturing company with five core systems that need to exchange data: an ERP system (Business Central 365), a production automation system (MES), a planning system, connections with logistics partners, and BI tooling for reporting.

Historically, these systems were connected point-to-point. The MES system pulled order data directly from the ERP. The planning system synchronized through its own custom connection. Logistics partners received a daily CSV export via FTP. The BI tooling pulled data from three sources using three different authentication mechanisms.

Each connection had been built individually (often as a “temporary solution”) and operated in its own way: its own credentials, its own error handling, its own retry logic. The overall picture was classic integration spaghetti: five systems didn’t mean five connections, but twenty possible connection lines, twelve of which were active.

It worked. Until it didn’t.

Challenge

After migrating from an on-premise ERP to Business Central 365 in the cloud, multiple connections broke. Direct database queries were no longer possible. FTP routes to the old data center had been shut down. And the new ERP required OAuth2 authentication: something the MES system and logistics partners couldn’t handle.

The question wasn’t how to repair twelve broken connections. The question was whether you should even want to.

The core problems on the table:

No central overview. Nobody could tell which systems exchanged what data, how often, or whether it succeeded. Diagnosing errors meant logging into five systems and searching through five separate log files.
No uniform authentication. The MES system used API keys. Logistics partners had FTP credentials. The BI tooling used service accounts. BC365 required OAuth2. Every system had its own security model.
No realtime data. Most connections ran as nightly batches. Order data was T+1 by default: what was entered today was available for planning and logistics tomorrow.
No scalability. Every new partner or new system meant a new integration project taking weeks. There was no standard, no reusability, no onboarding process.

Approach

We redesigned the integration layer from the ground up. Not a repair of existing connections, but an architectural shift: from point-to-point to hub-and-spoke, with Azure API Management (APIM) as the central platform.

APIM as integration hub

All systems communicate through APIM instead of directly with each other. The MES system sends requests to APIM. The planning system retrieves data through APIM. Logistics partners call API endpoints on APIM. The BI tooling consumes data through APIM.

APIM routes, authenticates, logs, and transforms. The backend systems (BC365, the MES, external services) are shielded behind the gateway. Consuming parties see a uniform API layer.

The result: instead of n-times-n possible connection lines, each system has exactly one connection: to APIM.

OAuth2 translation layer

The most concrete technical problem was authentication. The MES system exclusively supports API-key authentication. BC365 requires OAuth2 with Azure AD tokens. Without an intermediary layer, these two systems are incompatible.

In APIM, we solved this with an inbound policy:

The MES system sends a request with an API key in the header
APIM validates the key against a subscription
APIM performs a send-request to Azure AD to obtain a Bearer token
The token is cached (so that not every call triggers a new token request)
APIM sets the Bearer token as the Authorization header on the forwarded request to BC365

The MES system doesn’t need to know anything about OAuth2. No token refresh, no client secrets, no token cache. That complexity lives entirely in APIM configuration; no custom code, no separate middleware, no extra compute.

From FTP batch to OData APIs

BC365 offers standard OData endpoints for exposing business data. Instead of generating nightly CSV files and sending them via FTP, we made the relevant entities (orders, inventory, production orders) available as API endpoints through APIM.

Data is no longer pushed once per day. It’s retrieved when the consumer needs it, with the current state.

Webhook-driven events

For time-critical processes, we replaced polling and batch patterns with webhooks. When an order is created in BC365, the system sends an event notification to APIM, which routes it to the relevant consumers: the production system and the logistics partner.

The production system receives a webhook, retrieves the order details via the API, and starts production planning, within seconds of order creation. Not the next morning.

Centralized monitoring

With Application Insights as the logging backend, every API call is automatically recorded: latency, HTTP status code, consumer identity, payload size, failure patterns.

Problem diagnosis goes from “log into five systems and search through five log files” to “search one dashboard.” Who called what, when, with what result: everything in a single audit trail.

Controlled access for partners

External logistics partners get their own API subscription in APIM with rate limits, permitted endpoints, and API version management. Onboarding a new partner is no longer a development project: it’s a configuration change.

Result

The transformation delivered measurable improvements at every level:

Aspect	Before	After
Architecture	Point-to-point (n x n)	Hub-and-spoke via APIM (n)
Data freshness	T+1 (nightly batch)	Realtime via API and webhooks
Error detection	Next business day	Within seconds
Audit trail	Spread across five systems	Centralized in Application Insights
Onboarding new system	Weeks	Days
Partner access	FTP credentials per partner	Self-service API with rate limits

But the most important result is architectural. The company now has an integration layer that functions as a platform. New systems connect to APIM, not directly to five other systems. Authentication, logging, rate limiting, and version management are standard, not something that gets reinvented for every connection.

The twelve point-to-point connections were replaced by five APIM connections. That’s not simplification. That’s a different way of thinking about how systems communicate with each other.