Whether point-to-point connections or a central middleware — the architecture decides how expensive the tenth integration becomes. This category sets out the options: direct interfaces, queues and event-driven transfer, scheduled synchronisation, data mapping and transformation, interface versioning, and monitoring and retrying failed transfers. We explain when a dedicated integration layer pays off, which logging and traceability requirements are sensible and how to limit dependencies on individual providers. Documentation is part of it too: without described data flows, every later change becomes a risk — no matter how cleanly the first implementation was built. We also show which metrics describe the state of an integration — from the number of pending queue items to the duration of a full synchronisation.
On this page you will find all posts on the topic “APIs, middleware & architecture”. The newest posts are at the top.
Below each title there is a short text about it. Click on a post. Then you can read the whole text.
Above the list you also see the other topics. At the bottom, a link takes you back to all posts.
How internal AI assistants reach the ERP through the Model Context Protocol: business-level tools, per-user permissions, approval before writes, audit log.
Absorb an ERP outage: last valid stock and prices with an age stamp, buffered orders, conservative checkout rules and an orderly, deduplicated restart.
How events and message queues enable decoupled, resilient shop integrations: retry, partitioned ordering, idempotency and the dead letter queue explained.
Idempotency keys, exponential backoff with jitter and dead letter queues: how to make order and inventory syncs between store and ERP safely repeatable.
Webhooks or polling for shop-to-ERP integration? A comparison of latency, delivery guarantees, HMAC security and resilience with practical recommendations.