Enterprise systems integration: connecting ERP, CRM and e-commerce reliably, ready for AI agents

This guide is for CTOs, IT managers, operations leaders and e-commerce managers whose order, customer and stock data now lives in several systems that disagree with each other. It explains how to decide which system owns each record, how to choose an integration pattern for each flow, how to design for the failures every integration eventually meets, why the same interfaces decide what AI agents can safely do, and how to run an integration project in steps. It closes with a commerce example, a comparison of integration approaches and a readiness checklist.

In this guide

• Why integrations fail after launch
• Decide ownership before connections
• Choosing an integration pattern per flow
• Designing for failure: idempotency, retries and reconciliation
• Security and access for integrations
• API-first integration as the foundation for AI agents
• A step-by-step integration plan
• A commerce example and the platforms involved
• Connector, custom code, hub or events: the trade-offs
• An integration readiness checklist
• Planned guides in this cluster
• Limitations of this guide
• Frequently asked questions
• How this guide was made
• Next step

Why integrations fail after launch

Most integrations work on the day they go live. The trouble starts weeks later, when a payment provider resends an event, a warehouse system is down for an hour, a sales rep edits a customer in two places, or a price change reaches the store before it reaches the ERP. None of this is exotic; it is the normal weather of connected systems.

Three causes account for most of the damage:

• No agreed owner for each record. When both the CRM and the store can change a customer's address, the last write wins, and nobody knows which one was right.
• Happy-path design. The connector is built for the case where every call succeeds once, in order. Duplicates, delays and out-of-order messages then create double orders, missing invoices and stock that goes negative.
• No reconciliation. Without a routine that compares the systems, errors are found by customers and accountants instead of by the integration.

The fix is less about choosing a tool than about decisions made before any connector is configured: who owns what, which pattern each flow uses, and what happens when a step fails.

Decide ownership before connections

Start with a list of the business entities that cross system boundaries and assign each a system of record: the one place where the entity is created and changed. Every other system receives a copy and treats it as read-only, or sends change requests back to the owner.

The table is a starting point, not a rule. A B2B business with negotiated price lists may keep prices in the CRM; a marketplace may make its order management system the owner of orders. What matters is that each row has exactly one owner, written down and agreed by the business owners, not only by IT.

Two further decisions belong here. First, identifiers: every entity needs a stable key that all systems store, such as an order number or a customer ID, so records can be matched without guessing from names or e-mail addresses. Second, conflict rules: if a copy is edited anyway, decide whether the change is rejected, sent to the owner for approval or overwritten at the next sync.

Choosing an integration pattern per flow

There is no single right architecture. Most healthy integration landscapes mix patterns, chosen flow by flow.

A useful default for commerce is: synchronous calls only where a customer is waiting, events for changes that must travel fast, batches for bulk reference data, and a queue between the receiving endpoint and the business logic so that spikes and outages do not lose messages.

When a landscape outgrows point-to-point connectors, an integration hub gives it one place to map, route, retry and monitor flows, instead of logic scattered across a dozen scripts.

Designing for failure: idempotency, retries and reconciliation

Reliable integrations assume that every message may arrive twice, late, out of order or not at all, and design each step so that none of these causes damage.

Make writes idempotent. The HTTP specification, RFC 9110, defines an idempotent method as one where sending the same request several times has the same intended effect on the server as sending it once; PUT and DELETE are idempotent, while POST is not. Integrations that create records, which usually means POST, need their own protection: an idempotency key or the source record ID, stored with the result, so a repeated request returns the first result instead of creating a second order. The Enterprise Integration Patterns catalogue names the receiving side of this the Idempotent Receiver: a consumer designed so that processing the same message more than once produces the same result as processing it once.

Expect duplicates and disorder from webhooks. Stripe's webhook documentation is a clear example of what providers tell integrators. It says an endpoint may occasionally receive the same event more than once and advises logging processed event IDs and skipping those already seen. It states that events are not guaranteed to arrive in the order they were generated, and that in live mode undelivered events are retried for up to three days with exponential backoff. It also asks endpoints to verify the signature on each event, to return a success status quickly before any complex logic, and to process events through an asynchronous queue. Other providers differ in detail, so read each one's delivery rules, but design as if all of them behave this way.

Retry with care. Retry only failures that can succeed later, such as timeouts and temporary unavailability, not validation errors that will fail again. Space retries out with increasing delays and some randomness so that many clients do not retry at the same moment, cap the number of attempts, and retry only operations that are idempotent.

Park what cannot be processed. After the last retry, move the message to a dead-letter queue with its error, alert a named owner and give that person a way to fix and replay it. A failure nobody sees is worse than one that stops the flow.

Handle ordering explicitly. When the order of events matters, such as an order cancelled before its payment arrives, carry a version number or timestamp from the owning system and ignore updates older than the one already applied, or fetch the current state from the owner instead of trusting the event body.

Reconcile on a schedule. Once a day, or more often for payments, compare the systems: orders in the store against orders in the ERP, captured payments against invoices, stock in the warehouse against stock on the site. Report the differences, fix their causes and replay the gaps. Reconciliation turns "we think it is in sync" into a number someone can check.

Security and access for integrations

Integrations hold some of the most powerful credentials in a company: keys that can create orders, issue refunds and read every customer record. Treat them accordingly:

• give each integration its own account with the narrowest role that works;
• keep secrets out of code, and rotate them on a schedule and when staff change;
• verify signatures on incoming webhooks and reject stale timestamps;
• encrypt data in transit and at rest, and log access to personal data;
• review integration code like any other code, because it is code.

Netbase's published security practices include secure code review and version control, TLS in transit and AES at rest, role-based access control, MFA for admin dashboards, vulnerability scanning and penetration testing, and disaster recovery; NDAs, DPAs and SLAs are available on request, and contributors work under NDA. These are practices, not a guarantee about any particular system.

API-first integration as the foundation for AI agents

AI assistants and agents that check order status, draft a refund or update a CRM record do not need a separate integration layer. They need the one this guide describes. An agent reading nightly exports sees yesterday's stock; an agent writing straight into a database bypasses the owner, the validation and the audit trail. Reliable, documented APIs are what turn an AI pilot into something operations can trust, and where AI integration starts. For when an agent is the right tool at all, compare AI agents and workflow automation.

Two controls belong in the flow, not in the prompt. High-impact actions such as refunds, price changes and credit limits go to an approval queue where a named person confirms them. And every agent call is logged with the request, the data it read and the result, so an auditor can reconstruct why a record changed.

AI also helps build and run integrations: drafting field mappings from sample payloads for an analyst to verify, grouping dead-letter failures by likely cause, and flagging unusual gaps in reconciliation reports. An engineer or data owner still approves every mapping and every replay. Where the goal is an agent that acts across systems, Netbase's agentic AI automation service builds on these same interfaces.

A commerce example and the platforms involved

Geo-Tek IT Solutions (Cyprus). Netbase built an e-commerce platform for Geo-Tek IT Solutions. The client reported revenue up 36% in the first quarter after launch, engagement up 35%, repeat transactions up 24% and order processing time down 30%. These figures describe the engagement as a whole, not the integration layer on its own, and depend on the client's baseline and market. The order processing result is a reminder that integration work is judged by operational measures, not by the number of connectors. Read the Geo-Tek platform case.

Headless reward shop platform (client not named). For a Dubai-based loyalty and rewards company, Netbase connected a headless Magento reward shop platform to the client's own points middleware, ordering service and product catalogue, with webhooks for real-time changes and a scheduled sync as the failover. No result figures are published for this record. Read the reward shop platform record.

Platforms. Netbase has delivered commerce platforms on WooCommerce, Magento 2, Laravel and headless commerce, and its published stack also names PrestaShop, OpenCart, Shopware, CS-Cart, Shopify, Salesforce, Akeneo, Odoo and Symfony. In integration terms, that list spans the store, CRM, product information and ERP layers that the entity table above connects.

Reusable modules. Netbase's productized module library includes a CRM and B2B sales engine, a workflow automation toolkit, an AI chatbot and WorkChat integrator, Smart ERP Light, a real estate digital toolkit and an e-commerce accelerator. Where one of these fits a flow, it can shorten delivery; where none fits, the flow is built for the systems you already run.

Integration is most often the limiting factor in retail and commerce, where orders, stock and payments cross several systems every minute. Read how Netbase approaches storefronts, marketplaces and order operations in retail and e-commerce.

Connector, custom code, hub or events: the trade-offs

A common path is to start with connectors, reach their limits on error handling and visibility, and then consolidate into a hub. Planning for that step early, by keeping contracts and identifiers consistent from the start, makes the move far cheaper.

An integration readiness checklist

• Every entity that crosses systems has one named system of record.
• Every flow has a pattern, a timing need and a business owner.
• Every record carries a stable identifier stored in all systems.
• Create operations are idempotent, with keys stored alongside the result.
• Incoming webhooks are verified, queued and processed asynchronously.
• Retries are limited, spaced out and applied only to temporary errors.
• Failed messages land in a dead-letter queue with an alert and a replay path.
• A reconciliation report compares orders, payments and stock on a schedule.
• Each integration uses its own least-privilege credentials, rotated on a schedule.
• Tests cover duplicates, reordering, outages and peak volume.
• A runbook explains how to diagnose and replay each flow.
• AI agents call the same documented APIs with their own least-privilege credentials, and high-impact actions wait for human approval.

Planned guides in this cluster

This pillar anchors a set of deeper guides now being planned: ERP, CRM and e-commerce integration architecture; an API integration project checklist and its failure modes; custom ERP compared with off-the-shelf ERP; and designing reliable webhooks, retries and reconciliation. Until they are published, the sections above cover the essentials of each.

Limitations of this guide

This is practical guidance from Netbase delivery experience, not original research, and it does not replace an assessment of your own systems. The provider behaviour described from Stripe's documentation applies to Stripe and was checked on the access date; other providers set their own delivery and retry rules. The Geo-Tek results were reported for that engagement as a whole and depend on its baseline and market. Netbase's security practices are described as practices, not as a guarantee of any system's security.

How this guide was made

The Netbase Editorial Team wrote this guide from Netbase's published commerce, security and module-library pages, the Geo-Tek case study and public documentation from the IETF, Stripe and the Enterprise Integration Patterns catalogue. David (CEO) reviewed every Netbase fact. External sources are cited with access dates. Drafting used AI assistance (Claude). Its purpose is to help buyers plan integrations that keep working after launch.

Next step

Share the systems you run, the flows that break most often and any deadlines, and we will book a solution review to map ownership, patterns and failure handling for your landscape. You can also see the related service or browse more Netbase insights.

Related services and solutions