API orchestration: connecting commerce systems with ERP…

Q: What happens when carriers or payment providers fail?

Fallback routes, queueing and clear escalation. Orchestration defines synchronous vs asynchronous steps; new brands connect via adapters.

API & integration development

The Challenge

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.

Our Solution

Integration landscape

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.

Results

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.

Message model and adapters

Canonical order events

A shared schema for order, shipment and return reduces mapping errors; versioning allows parallel adapter generations.

Idempotency and retry

Consumers use deduplication keys; backoff and dead-letter prevent endless retries on business errors.

Operations and scaling

Kubernetes and release trains

Services run containerised with separate release trains per brand; canary rollouts for risky transforms.

Onboarding new brands

Checklists for adapters, sandbox tests and go-live shorten time-to-market without new point-to-point scripts.

Sandbox environments mirror production ERP and carrier stubs for realistic integration tests.

Canary rollouts for risky transformations minimise impact on live orders.

Error handling and operations

Dead-letter and manual reprocessing

Failed messages land in monitored queues with retry policy; operations can replay individual cases manually.

Root-cause analyses feed adapter updates and transformation rules.

Backlog thresholds and error rates are contractually agreed with retail and logistics.

SLA with retail and logistics

Backlog thresholds and error rates are agreed with operations; escalation happens before customer visibility.

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

Features

Feature overview

Routing and transformation between channels
Idempotent consumers with backoff
Observability: metrics, logs, alerting
Security: OAuth2, webhook signatures

Frequently asked questions: API orchestration for commerce, ERP and carriers

What is API orchestration—and when do you need it?

A central layer coordinates flows between shop, ERP, warehouse, carriers and finance—instead of messy point-to-point links. Useful with several systems and changing brands or channels. Delivered through API and interface development and system integration.

Middleware or custom layer—what fits mid-sized companies?

Depends on integration count, team skills and budget—from lean in-house middleware with queues to orchestrated flows with OpenAPI contracts. Maintainability, error paths and monitoring matter more than tool marketing. ERP projects tie in ERP implementation.

How is ERP connectivity made fault-tolerant?

Retry logic, dead-letter queues, idempotent order handling and manual reconciliation views for support. “Fire and forget” does not scale in retail—order events are validated, enriched and delivered reliably.

How are monitoring and data consistency ensured?

End-to-end metrics per order, alerts on sync drift and regular reconciliation jobs. Master data, shipment status and stock must be traceable for operations. Operations supported by DevOps consulting; in Odoo landscapes also Odoo development.

What happens when carriers or payment providers fail?

Fallback routes, queueing and clear escalation—the process does not fail silently. Orchestration defines synchronous vs asynchronous steps. New brands connect via adapters instead of one-off scripts—planned through custom software development.

Transparency about this case study

So the statements above can be judged properly, we disclose what kind of project this is, what the results are based on and who reviewed the text. More on our project approach and an overview of all reference projects.

Case type: Client project, anonymised or shown under a project name – Real project; company name, industry details or individual figures are generalised at the customer's request.
Measurement basis: Number of manual correction runs between shop, logistics and ERP plus runtime of the nightly syncs.
Measurement period: Delivery phase and ongoing operations after go-live
Data source: IT management at the multi-brand retailer and interface monitoring.
Scope of the figures: Figures are rounded and stripped of identifying details; the order of magnitude is preserved.
Publication status: Evidence pending in the new approval register
Approval scope: The existing anonymised publication remains available; case-specific approval evidence still needs to be recorded in the new register.
Evidence record: Internal project file and anonymised reference record.
Technical review: Björn Groenewold, Managing Director of Groenewold IT Solutions GmbH and Hyperspace GmbH – last reviewed on 8 September 2026

Change history

8 September 2026Evidence details added to “API orchestration between retail and ERP”: case type, measurement basis, data source and technical review.
24 February 2026Results and solution description of “API orchestration between retail and ERP” revised; the German version was aligned.
1 January 2025Case study “API orchestration between retail and ERP” published.

API orchestration: connecting commerce systems with ERP and carriers