Short answer: good ERP, PIM and B2B ecommerce integration starts by deciding which system owns each type of data. Then teams define how that data moves, how often it updates, what happens when it fails and how much consistency the customer experience requires. Connecting APIs without those decisions simply moves disorder from one system to another.
In B2B projects, integration often becomes the technical centre of ecommerce. The front end can be excellent, but trust disappears quickly if it shows the wrong price, stale availability or inconsistent product information. If an order is duplicated or lost before it reaches the ERP, the issue is no longer cosmetic; it affects operations, invoicing and service.
Start by mapping the systems
Before defining endpoints, list the systems involved and what each one does today. ERP, PIM, CRM, WMS, DAM, ecommerce, marketing tools, carriers, BI and identity systems may all participate. They do not all need direct connections to one another.
The objective is to avoid a web of point-to-point integrations that becomes difficult to maintain. In many architectures, ecommerce consumes defined sources and publishes transactions or events through controlled flows.
Define a source of truth for each data domain
The source of truth does not have to be one system for everything. It needs to be unambiguous by data type. The ERP may own accounts, commercial conditions, credit and orders. The PIM may own titles, attributes, taxonomy, translations and product relationships. A DAM may own files. Ecommerce may own saved lists, user behaviour and experience-specific content.
What matters is that each change has an official home. If a description can be edited in both PIM and ecommerce without rules, the versions will eventually diverge.
Product: separate commercial, technical and editorial data
A B2B product contains different classes of information. SKU, selling unit, tax family and sale status may originate in the ERP. Specifications and enriched attributes may come from the PIM. Application content and SEO copy may be managed in the CMS.
There is no need to force every field into one platform. The important thing is to know where each field comes from and which team owns it. That separation lets the catalogue become richer without turning the ERP into an editorial system.
Pricing: avoid duplicating the whole commercial engine when possible
B2B prices can depend on customer, group, market, currency, volume, contract and date. Rebuilding all those rules inside ecommerce creates a risk of divergence. Some projects request a calculated price from the ERP; others synchronise relevant price tables.
The right model depends on volume, performance and real-time requirements. The essential requirement is being able to explain why the displayed price is correct and what happens when the source is unavailable.
Stock: real time is not automatically better
Calling the ERP on every page view can create latency and dependency. Periodic synchronisation may be sufficient if the business tolerates small differences. Some companies display availability ranges or states rather than exact units.
The decision should start with the promise made to the customer. A site that says “available now” needs a different level of assurance from one that says “typically available within 48–72 hours”.
Customers and accounts: synchronise identity and commercial conditions
In B2B, the digital user must connect to the existing commercial account. Validation may be required before private prices are activated, several users may belong to one company, and existing addresses or payment conditions may need to be inherited.
Define the stable account identifier. A person’s email address is rarely enough. Also decide which changes users can make online and which changes require validation before returning to the ERP.
Orders: design idempotency from the start
An order should not be duplicated because a request is retried. APIs, webhooks and queues can all retry work. The integration needs to recognise a transaction that has already been processed and return a consistent response.
Idempotency is especially important around payments and order creation. A stable external identifier and explicit state history allow safe retries without duplicate effects.
Use queues for operations that do not need to block the user
Not everything has to complete while the user waits. A portal can confirm an order and send it to the ERP through a queue, provided the customer sees a clear state and the business monitors processing. The same applies to bulk catalogue updates and document processing.
Queues absorb spikes and allow temporary errors to be retried. But they require visibility. Storing jobs is not enough; operators need to know which jobs failed, how long they have been failing and why.
Design the degraded state explicitly
The question “what happens if the ERP is down?” should be answered before launch. Perhaps the catalogue remains available but ordering is disabled. Perhaps the last known availability is shown with a notice. Perhaps selected customers can prepare an order that remains pending.
A defined degraded state prevents an internal dependency from making the entire customer experience unavailable.
Errors: distinguish temporary failure, invalid data and conflict
Not every error should be retried in the same way. A timeout may be temporary. A missing SKU requires a data fix. An impossible price may reveal conflicting rules. Classifying errors makes automated retries safer and ensures human attention is reserved for issues that need it.
A simple operational dashboard is often more useful than raw technical logs when customer service needs to understand one specific order.
Observability: follow each entity through the integration
To debug integrations, teams need to trace a product, customer or order across systems. Correlation identifiers, timestamps, synchronisation status and the origin of changes make it possible to answer “why did this order not arrive?” without manually reconstructing several log files.
Security: integrate with least privilege
An ecommerce credential should not have unrestricted access to the ERP. Limit permissions by function, keep secrets outside source code, rotate credentials and log sensitive operations. B2B integrations should also review the exposure of customer-specific commercial information.
Choosing between batch, events and direct queries
Batch processing works well for large volumes that do not require immediacy, such as some overnight catalogue updates. Events are useful when a change needs to propagate quickly. Direct queries are appropriate when the response genuinely needs the current source at that moment.
Real architectures often combine all three. Selecting one pattern for every data type creates unnecessary extremes.
Integration also affects SEO and GEO
Search engines and AI systems need stable, accessible content. If useful product attributes only appear after private calls or fragile client-side rendering, visibility suffers. A PIM can feed structured public pages while customer-specific pricing and stock remain private.
This separation allows a company to be found by product, application and specification without exposing sensitive commercial data. Our article on B2B dealer portal capabilities shows how those data foundations become useful customer features.
Checklist before connecting ERP, PIM and ecommerce
- Inventory of systems and owners.
- Source of truth by data domain.
- Stable identifiers for product, account and order.
- Frequency and direction of every synchronisation.
- Retry and idempotency policy.
- Degraded state for dependency failures.
- Operational monitoring and alerts.
- Security and credential rotation plan.
- Testing with real volumes and edge cases.
- Data reconciliation procedure.
At CODE B2B Commerce, we treat integration as part of the product rather than a technical phase added later. The portal can only deliver a reliable experience when the data architecture supports it.
Frequently asked questions about ERP, PIM and B2B ecommerce
Should ecommerce always query the ERP in real time?
No. It depends on the data and the promise to the customer. Pricing or credit may require high freshness; many attributes can be synchronised periodically.
What data should a PIM own?
Typically enriched attributes, taxonomy, relationships, translations and product documentation. The exact boundary depends on the stack and ownership model.
What is idempotency in ecommerce integration?
It is the ability to process a repeated operation without duplicating the effect. If an order is sent twice because of a retry, the ERP should still create one order.
How do you stop an ERP outage taking down the portal?
Decouple operations where possible, use caches or queues and design a degraded state. The interface should know which functions can remain safely available.
Reconciliation: make sure the systems still tell the same story
Alongside individual error monitoring, schedule regular reconciliation. Compare portal orders with ERP orders, active PIM products with published products, and enabled accounts with their commercial conditions. An integration can appear technically healthy while accumulating silent differences. Reconciliation finds those gaps before a customer does.