API orchestration: connecting commerce systems with ERP and carriers

Many point-to-point links

Each new brand introduced its own CSV or FTP flows. Issues surfaced only when parcels or stock levels diverged.

Operations maintained scripts without shared monitoring; retry logic differed per channel.

We wanted to swap adapters—not build another nightly script every time.

Carriers, ERP and shop with different models

Orders, returns and stock movements used different fields and statuses. Without a canonical model, mapping errors multiplied.

Each new brand brought its own field names; operations lost time on manual reconciliations instead of structured error handling.

Returns and partial shipments used different status codes per carrier—without mapping, stock levels became wrong.

Target state: event hub with observability

A central platform should validate, enrich and reliably deliver events—with idempotency, dead-letter queues and operations dashboards.

New brands should connect without point-to-point scripts.

Carrier changes must not destabilise the ERP model—only swap the adapter.

Operations needs unified error codes instead of scattered log files per channel.

Integration backlogs should escalate before customers notice.

Retail and logistics expected dashboards and SLAs instead of nightly manual correction runs.

Integration platform and message model

We introduced a shared message model: order events are validated, enriched and reliably delivered to ERP and carriers. Retries are idempotent; failures land in monitored dead-letter queues.

Architecture aligned with our API and integration development; practice notes in the interfaces blog category.

Phase 1: canonical events and routing

Kotlin/Spring services normalise shop events; RabbitMQ routes by brand and target. OpenAPI describes adapter interfaces for new brands.

OAuth2 and webhook signatures secure external channels.

Schema registry documents field mappings between shop, ERP and carrier status values.

Sandbox tests with ERP and carrier stubs run before each new brand goes live.

Phase 2: observability and carrier adapters

Prometheus metrics, structured logs and alerting cover backlogs and error rates. Carrier adapters swap via configuration.

Operations dashboard shows queue depth, retry rate and dead-letter count per brand in near real time.

Runbooks describe manual replay and escalation for business mapping errors.

If a message fails three times, a human should see it—not vanish quietly in logs.

Fewer manual correction runs

Operations has dashboards for backlogs and error rates; new brands connect via configuration and adapters instead of one-off scripts.

Stock drift between shop and ERP dropped measurably versus the pre-integration baseline.

Carrier changes succeeded through adapter swap without ERP model changes.

Mean time to recovery on integration failures shortened through dead-letter workflows.

Operations KPIs under 24/7 monitoring

Mean time to recovery on integration failures shortened; dead-letter queues are cleared daily.

New brands go live faster because adapters and configuration replace point-to-point scripts.

Release windows for adapter updates minimise risk during peak shipping periods.

Root-cause analyses feed adapter updates and transformation rules.

Schema registry and Git-versioned transformation rules make adapter changes traceable and testable.

Sandbox environments mirror production ERP and carrier stubs for realistic integration tests before go-live.

Delivery and operational support by Groenewold IT Solutions—event-driven integration Made in Germany.