Skip to main content
Talk to an expert
Adobe Commerce logo

Adobe Commerce integration for ecommerce

Adobe Commerce connects to the systems that run your business. Adobe Commerce is the commerce platform layer. iWeb defines the flows to ERP, PIM, payments, fulfilment, search, marketplaces and CRM so products, stock, pricing, orders and customers stay in step. Integrates with the ERP, PIM, OMS and operational systems commerce teams already run.

Also searched as: commerce platform, storefront, online store, shop platform, commerce engine.

Your systemsiWeb integration layerAdobe Commerce
Talk to an expertSee the estate map ↓
Works with - PIM (for product data) · ERP (for stock and pricing) · OMS or fulfilment (for order routing and dispatch) · CRM or CDP (for customer and consent data) · Search and recommendations engine
On this pageGet a brief reviewed
01 · What you get

What a Adobe Commerce integration gives you.

Product data published cleanly

Product teams own content in PIM; merchandisers trust that what they publish to catalogue is accurate, complete and in the right language for each channel.

Stock and pricing parity

Customers see accurate stock and price at checkout; finance sees the same price in the ERP invoice. No oversell, no price mismatches, no refund surprises.

Orders handed off without loss

Every web order reaches the warehouse or OMS, acknowledged and tracked. No silent order failures; no customer service blind spots.

Channels stay in sync

Product, stock and pricing changes propagate to marketplaces, POS and wholesale channels without manual intervention or lag.

Customer experience is unified

Customers see their account, order history and personalisation across web, app and store. Email marketing respects consent; support sees the full journey.

02 · When it's worth it

Where a Adobe Commerce integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Publish governed product data from PIM to storefront catalogues and category pages
Sync stock and pricing from ERP to checkout and cart in real time
Capture web orders and hand them off to ERP or OMS for fulfilment
Pull customer and consent records from CRM and marketing platforms into accounts
Push marketplace listings and channel-specific inventory to Amazon or eBay channels
Integrate search, recommendations and merchandising rules from dedicated search engines
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

Product content stays siloed in Adobe Commerce

By default, product attributes, images and taxonomy live only in the storefront database. Without a PIM, product changes ripple across channels manually, enrichment is ad-hoc, and a second storefront means duplicating and maintaining content twice.

Stock and pricing sync is a custom integration job

Adobe Commerce has no native, governed connector to pull stock and pricing from ERP systems. Retailers build custom REST or GraphQL integrations, often without clear ownership of data direction, refresh rates or fallback if the ERP is down.

Order handoff to ERP requires custom mapping

Orders captured in Adobe Commerce do not automatically flow to ERP or OMS. A custom integration is needed to map order lines, addresses, payment status and customer account references, and to handle exceptions like duplicate orders or failed acknowledgements.

Customer and consent data is fragmented

Adobe Commerce holds customer profiles, but consent preferences, marketing suppression and segment membership live in separate CRM or CDP systems. Bridging these requires custom sync logic, and unsubscribe events often go unheeded across channels.

Search and merchandising are bolt-on, not native

Adobe Commerce includes basic search, but dedicated search engines, facet tuning, zero-results handling and merchandising rules live in tools like Elasticsearch, Algolia or Coveo. Keeping index, rankings and rules in step with storefront content is a separate integration task.

Multi-channel inventory and pricing complexity

Without a channel management layer, stock and prices across web, marketplace, POS and wholesale channels are hard to allocate and reconcile. Oversell across channels, late syndication and channel-specific pricing rules create operational chaos.

04 · The real work

Product data that lives only in the storefront is data nobody truly owns; product feeds that have no monitoring are product feeds that eventually break.

05 · Where it sits

Where this integration sits in your estate.

Adobe Commerce is the commerce platform - the customer-facing experience, catalogue, checkout and account area. The iWeb integration layer wires it into the ERP, PIM, OMS, WMS and payments systems it depends on. The estate map helps agree ownership before anything is built.

Sits at the front of your estate. We wire Adobe Commerce into the finance, stock and product systems it depends on.

Customer-facing commerce
Commerce platform
Adobe Commerce
The storefront and customer-facing commerce platform layer for online sales and customer accounts
  • Product display and catalogue pages
  • Shopping cart and checkout experience
  • Customer account and session management
  • Promotional and discount rules applied at checkout
  • Order capture and customer messaging
iWeb integration layer
Systems behind the platform
Systems it depends on
PIM (for product data)ERP (for stock and pricing)OMS or fulfilment (for order routing and dispatch)CRM or CDP (for customer and consent data)Search and recommendations engineMarketplace connectors (Amazon, eBay)Payment processorsAnalytics and BI platforms
  • All product, stock, pricing and order operations
  • Customer identity and consent governance
  • Fulfillment workflows
  • Marketing and customer data flows
Connected neighbours
Integration layer
PIM
Provides authoritative product attributes, descriptions, images, variants and enrichment; Adobe Commerce syndicated from PIM via API feed.
Integration layer
ERP
System of record for stock levels, base pricing, customer accounts and order processing; Adobe Commerce queries for real-time or cached availability.
Integration layer
OMS or WMS
Receives orders from Adobe Commerce and orchestrates picking, packing and dispatch; sends back tracking and dispatch confirmations.
Integration layer
CRM or marketing platform
Receives customer profiles and behavioural events from Adobe Commerce; sends back consent and suppression rules for checkout and campaigns.
Integration layer
Search and recommendations
Indexes product data from Adobe Commerce; returns ranked results and merchandising rules to the storefront.
Integration layer
Marketplace and channel systems
Receive product feeds, inventory and pricing from Adobe Commerce; send back channel orders for unified fulfilment.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb wires Adobe Commerce into whatever ERP, PIM, OMS, WMS, payments and operational systems your estate already runs.

Systems behind the platform (examples)
  • PIM (for product data)
  • ERP (for stock and pricing)
  • OMS or fulfilment (for order routing and dispatch)
  • CRM or CDP (for customer and consent data)
  • Search and recommendations engine
  • Marketplace connectors (Amazon, eBay)
  • Payment processors
  • Analytics and BI platforms
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into COMMERCE & SALES CHANNELS
←From COMMERCE
↔BOTH WAYS
Product catalogue from PIM: Product attributes, descriptions, images, variants, taxonomy and enrichment flow from the PIM system into Adobe Commerce product records, categories and catalogue pages
The storefront becomes the display layer; PIM owns the truth.
Stock and pricing from ERP: Stock levels, base pricing, promotional prices and customer-specific pricing move from the ERP into checkout, cart, product detail pages and availability messaging
Real-time or batch updates keep pricing and stock parity during peak and quiet periods.
Orders to ERP or OMS: Customer orders captured at checkout flow to the ERP or OMS for acknowledgement, picking, packing and dispatch
Order headers, lines, addresses, payment status and customer records move as a complete transaction.
Customer and consent data to CRM: Customer profiles, email addresses, consent preferences, purchase history and behavioural events flow from Adobe Commerce to marketing and CRM platforms for segmentation, campaigns and lifecycle marketing.
Returns and refund events: Return authorisations and refund confirmations flow from the storefront back to the customer, to ERP for credit memos and cost-centre reconciliation, and to payment processors for settlement.
Listings and inventory to marketplaces: Product feeds, inventory levels and pricing sync to Amazon, eBay or specialist channels
Channel-specific product data, SKU mappings and stock allocation rules keep marketplace presence up to date.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Design the ownership map

    iWeb defines which system owns product, pricing, stock, customer and order data, and which system is the display layer. Adobe Commerce becomes a channel, not a master.

  2. 02
    Build governed data flows

    iWeb creates API-based, monitored integrations for each data flow: PIM to storefront, ERP to checkout, orders to fulfilment, customer consent to email. Each flow has a named owner, SLA and exception queue.

  3. 03
    Set up failover and rollback

    If ERP stock goes stale, if PIM publish fails, if orders cannot reach fulfilment, iWeb defines the fallback. Caching, queuing, manual intervention paths and monitoring ensure the storefront does not hang or serve bad data.

  4. 04
    Migrate existing data cleanly

    If moving from another platform or retiring a legacy storefront, iWeb maps product, customer and order histories into Adobe Commerce and downstream systems without gaps or duplicates.

  5. 05
    Manage multi-channel complexity

    iWeb sets up channel-specific product data, pricing rules, inventory allocation and order routing so web, marketplace, POS and B2B channels stay in step.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataProduct catalogue, attributes, variants, descriptions, images, taxonomy and enrichment
Source / ownerPIM
Maintained byProduct and merchandising teams
NotesAdobe Commerce is the display layer; all changes originate in PIM and are syndicated to the storefront via API feed or GraphQL subscription.
DataBase pricing, list pricing, promotional pricing and customer-specific pricing
Source / ownerERP
Maintained byFinance and pricing teams
NotesAdobe Commerce caches or queries pricing at checkout; price truth is always in ERP. Pricing changes are published on a defined schedule or triggered by rule changes.
DataStock levels, availability, reservations and allocation across channels
Source / ownerERP or OMS
Maintained byOperations and inventory teams
NotesAdobe Commerce queries or caches stock for display; stock moves in ERP or OMS as orders are picked and packed. Allocation rules prevent oversell across channels.
DataOrders, order lines, addresses, payment status and order history
Source / ownerERP or OMS
Maintained byFulfilment and operations teams
NotesAdobe Commerce captures the order at checkout; a governed integration pushes the complete order to ERP or OMS for acknowledgement, picking and dispatch. Order status flows back to the storefront.
DataCustomer profiles, email addresses, phone numbers, account preferences and purchase history
Source / ownerCRM or customer database
Maintained byMarketing and customer service teams
NotesAdobe Commerce captures web customer records; consent and suppression rules are enforced in CRM and synced back to the storefront. Account linking reconciles web, POS and B2B customers.
DataBasket, checkout flow, cart abandonment messaging and promotional rules
Source / ownerAdobe Commerce
Maintained byEcommerce and marketing teams
NotesThe storefront owns the real-time cart and checkout experience. Promotions, discounts and payment method selection apply at the moment of transaction. Basket contents are logged for marketing and analytics.
DataIntegration transport, data mapping, monitoring, exception handling and fallback logic
Source / ownerIntegration layer (governed by iWeb)
Maintained byIntegration and operations teams
NotesEach data flow has a named owner, SLA, exception queue and rollback path. Monitoring detects stale syncs, missing orders and consent drift.
10 · Experienced integrator

Built this before

iWeb has integrated Adobe Commerce into large B2B and B2C estates where product, stock, pricing, orders and customers must stay governed and synchronised. We understand the integration patterns, the ownership tensions, and the monitoring discipline that keeps a commerce platform from becoming a data island.

We design ownership maps that place PIM at the centre of product governance, ERP as the source of stock and pricing truth, and the storefront as a display layer, not a master database.
We build API-based flows for every data direction: catalogue feeds from PIM, stock and pricing from ERP, orders to OMS or fulfilment, customer and consent data to and from CRM platforms.
We set up monitoring, exception queues and fallback paths so stale stock, pricing drift, lost orders and consent mismatches are caught and resolved, not discovered by customers.
We integrate search, recommendations, marketplaces and multi-channel inventory so product, stock and pricing changes propagate cleanly across web, app, POS and wholesale channels without oversell.
We manage replatforms and data migrations so product, customer and order histories move cleanly from legacy storefronts into Adobe Commerce and downstream systems.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify product feed completeness: all PIM attributes, variants and images are received and indexed in Adobe Commerce within SLA.
Check stock and pricing parity: list price and real-time stock queried from ERP match the values shown on product detail and at checkout.
Confirm order capture and handoff: test orders are created at checkout, pushed to ERP or OMS and acknowledged within SLA without duplication.
Test consent and suppression: unsubscribe in CRM is reflected in checkout within 1 hour; opted-out customers do not receive promotional emails.
Validate fallback and failover: if ERP goes offline, storefront shows cached stock and pricing; orders queue locally and retry after ERP recovers.
Monitor exception handling: failed product syncs, late orders and pricing mismatches are logged in the exception queue and trigger alerts.
Verify multi-channel inventory: test that stock allocated to web is reserved across marketplace and POS channels; oversell is prevented.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Product data drifts between PIM and storefront

Product feeds fail silently or are skipped during busy periods. Merchandisers update PIM, but storefront shows old content. Marketplaces get stale feeds. Root cause: no SLA, no exception monitoring, no clear owner of the sync.

Stock goes stale, customers oversell

ERP stock sync lags during peak traffic. Adobe Commerce shows old stock, customer orders exceed available inventory, warehouse cannot fulfil. OMS or fulfilment sees the overcommitment too late. Root cause: refresh rate too slow, no real-time toggle, no fallback to ERP queries.

Pricing mismatches at checkout

ERP base price changes, but Adobe Commerce cache shows old price. Customer is charged differently to what invoice says. Finance reconciliation fails. Root cause: pricing sync batches are async, cache TTL is unclear, no price-validation rules at checkout.

Orders disappear between storefront and ERP

Order is captured in Adobe Commerce but does not reach the ERP or OMS. Warehouse never picks it. Customer never gets notified. Root cause: custom order sync has no idempotency, no dead-letter queue, no acknowledgement loop back to the storefront.

Customer account fragmentation

Customer registers on web, but profile does not sync to CRM, so marketing emails do not know about them. Unsubscribe in email marketing, but storefront still sends transactional mail. Root cause: no two-way customer sync, consent is not mapped, no suppression list pull from CRM to checkout.

Marketplace inventory and pricing go out of sync

Product feed to Amazon succeeds, but stock allocation from ERP fails. Marketplace shows 10 units but warehouse has 3. Second channel breaks the feed silently. Root cause: no channel-level inventory locking, pricing rules are not versioned, feed monitoring is weak.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about Adobe Commerce integrations.

Who owns product content: Adobe Commerce or PIM?

PIM owns product attributes, descriptions, images, variants and taxonomy. Adobe Commerce displays the catalogue. Changes always originate in PIM; the storefront is the consumption layer. This clarity prevents duplicate data maintenance and manual inconsistencies.

How do stock and pricing stay accurate at checkout?

Stock and pricing are queried from ERP in real time or cached with a short TTL (time to live). If ERP is unreachable, the integration can fall back to cached data, zero-stock warnings or manual approval. iWeb designs the fallback path and monitoring so customers never see phantom stock.

What happens to an order between Adobe Commerce and ERP?

The storefront captures order header, lines, addresses, items and payment status at checkout. A governed integration pushes the complete order to ERP or OMS within seconds. ERP acknowledges the order; status flows back to Adobe Commerce. If the push fails, the order is queued until delivery succeeds.

How does consent and suppression work across web and email?

Customer opts in or out on the web storefront; the preference flows to the CRM system. When the CRM suppression list is pulled into checkout, marketing-email subscribers do not receive promotional messages. Unsubscribe in email marketing suppresses the customer in Adobe Commerce.

Can Adobe Commerce handle multiple sales channels at once?

Yes. The storefront is one channel. Inventory, pricing and product feeds also go to Amazon, eBay, POS and B2B procurement platforms. iWeb designs channel-specific data rules (e.g. different prices for different channels) and allocation logic so one stock number does not oversell.

How is search and merchandising integrated?

Adobe Commerce includes basic search, but dedicated search engines (Elasticsearch, Algolia, Coveo) are often used for relevance, facets and zero-results handling. iWeb syncs product data to the search index and pulls back ranking and recommendation rules so search experience is governed alongside catalogue.

What if the ERP goes down?

iWeb designs a fallback: stock and pricing are cached or queried from a resilience layer; orders are queued locally in Adobe Commerce or a message broker until ERP comes back. Customers are not blocked from browsing or buying; exceptions are logged and reconciled once the ERP recovers.

How do we avoid duplicate orders or lost orders?

iWeb designs idempotent order flows: each order has a unique ID, and the integration detects duplicates before pushing to ERP. If an order fails, it sits in a dead-letter queue until manually reviewed or retry logic succeeds. Monitoring alerts on missing orders so they are not silently lost.

Can we replatform from another storefront without losing data?

Yes. iWeb migrates product, customer, order and pricing history from the old platform to Adobe Commerce and downstream systems without gaps. Product data is validated against PIM; customer records are reconciled; order history is imported for reporting.

Who owns the integration when something breaks?

Each data flow has a named owner (e.g. product sync owner, order sync owner, stock sync owner). iWeb defines the SLA, the exception queue, the runbook and the escalation path so problems are owned and resolved, not discovered by customers.

How do we measure if integrations are working?

iWeb sets up monitoring dashboards for each flow: product feed success rate, order latency, stock freshness, pricing parity checks and customer consent sync lag. Alerts trigger if freshness degrades or syncs fail. Metrics are reviewed in weekly operations reviews.

What does a governance model look like for Adobe Commerce?

The ownership map names the system of record for each data type (PIM for products, ERP for pricing and stock, CRM for customers, Adobe Commerce for orders and baskets). Each team owns their part. iWeb designs the data flows, monitoring and exception handling that connect them.

14b · Same category

Other commerce platforms integrations.

Adjacent integrations in the same category. Same shape of work, different vendor.

Commerce platforms
Next step

Have a Adobe Commerce integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →