Adobe Commerce integration guide

Adobe Commerce sits between an ERP, PIM, OMS, payment gateway, tax engine, search, and AEM. This guide shows how to plan those connections so order state, inventory, and pricing stay trustworthy once real traffic and real exceptions arrive.

Book discovery · Read integration services

In this guide

• Why Adobe Commerce integrations break
• Decide ownership before connectors
• Match the pattern to each flow
• Design for the failures Adobe Commerce will throw
• Test the exceptions, not the demo
• Operate with monitoring and runbooks
• FAQs

Why Adobe Commerce integrations break

Adobe Commerce rarely fails because a connector is missing. It fails because the systems around it disagree about the same record. The ERP holds the authoritative price while a catalog price rule overrides it on the storefront. Multi-Source Inventory reports stock per source while the OMS reserves against one pooled number. A payment authorizes at checkout but captures hours later through a queue consumer. An order reads complete in the admin and unshipped in the warehouse. Each gap becomes a manual export, a one-off script, or a launch rule that only one person remembers.

Treat Adobe Commerce as one participant in a wider operating model, not the system of record for everything it can store. The aim is not to wire up every endpoint quickly. It is to make each flow traceable, supportable, and safe to change after go-live.

Decide ownership before connectors

Before choosing REST, GraphQL, or a message queue, decide which system owns each object: product and attribute set, category, base price, catalog and cart price rules, MSI source and stock, customer, company account, shared catalog, negotiable quote, address, cart, order, invoice, shipment, credit memo, payment, tax, and CMS content. For each, name the system that can create it, the one that can update it, and the ones that may only read it.

Adobe Commerce makes this urgent because it can plausibly own almost any of these. A clear ownership map keeps the platform, ERP, PIM, and middleware from quietly doing each other's job, and it exposes where "bidirectional sync" is really two systems competing to be the source of truth.

Match the pattern to each flow

Adobe Commerce gives you several integration surfaces, and the mistake is forcing one on every flow:

• Synchronous REST and GraphQL for narrow, customer-facing reads and writes such as price, availability, and quote operations.
• Async and bulk REST for high-volume catalog and inventory loads that must not block a web request.
• The message queue framework (RabbitMQ) for order export, ERP acknowledgements, and any flow that needs durable, retryable, asynchronous handling.
• Scheduled imports, exports, and cron-driven jobs for nightly enrichment, reconciliation, and supplier files or EDI.

Choose per flow against latency, volume, and who owns recovery, not against what is fastest to stand up first.

Design for the failures Adobe Commerce will throw

Assume failure and design for it before launch. Indexers fall behind and serve stale prices. Cron or queue consumers stop and orders stop exporting. Async bulk operations partially succeed. Payment captures arrive late. MSI stock shifts between cart and checkout. A cloud deploy enters maintenance mode mid-flow. A reliable design specifies idempotency keys, duplicate detection, retry windows, dead-letter handling, alerts, and a documented replay path for every flow.

Test the exceptions, not the demo

Test data has to include the cases that actually generate support tickets: negotiable quotes converted to orders, B2B shared-catalog pricing, partial shipments, orders split across MSI sources, out-of-stock lines, failed and delayed captures, duplicate customer records, tax-exempt buyers, multi-store-view and multi-currency orders, and credit memos with partial refunds. A happy-path integration that only passes the demo is not production-ready.

Operate with monitoring and runbooks

Monitoring should answer a business question, not just whether an endpoint returned 200. Track export delay, queue depth, stalled consumers, rejected payloads, indexer lag, settlement mismatches, and manual interventions. Each alert needs a runbook that names the owner, the likely cause, the recovery action (pause a consumer, reindex, replay a message, reconcile finance), and the escalation path.

Delivery guidance for Adobe Commerce integration

Most Adobe Commerce integrations can be built; the connectors are well understood. The harder question is who owns each decision once the connection moves production data. Run a design workshop that names the objects most likely to cause downstream damage: SKUs and attribute sets, customer groups and company accounts, catalog and cart price rules, MSI sources, order and fulfillment state, invoices, credit memos, and content references. Give each one a source of truth, an allowed update path, a fallback rule, and a named owner for exceptions. Without that, teams patch symptoms in cron jobs, middleware mappings, or theme code, and every urgent fix becomes another hidden rule.

Decisions to make before implementation

• Define the source and consuming systems for every critical object, including who can correct bad data and who can only request a correction.
• Choose the pattern per flow: synchronous REST/GraphQL, async or bulk REST, RabbitMQ, scheduled job, iPaaS, or file/EDI.
• Document the identifiers that join records across systems: SKU, order increment ID, entity ID, environment prefixes, legacy IDs, and finance references.
• Set latency expectations in business terms: checkout-blocking, same-day operational, next-cycle enrichment, or finance-close reconciliation.
• Design idempotency, duplicate detection, retry windows, dead-letter handling, and manual replay before the first cutover rehearsal.
• Assign an owner to each failure mode with authority to retry, repair, suppress, or escalate.

A build sequence that reduces risk

Start with a thin vertical slice that exercises the real ownership model: one representative product or order, one transformation, one negative test, one retry, one alert, one support action. That proves the delivery path, and whether the named owners can actually make decisions during a failure, before the team scales mappings.

Broaden the second slice to realistic exceptions: missing attributes, stale MSI stock, duplicate identifiers, delayed captures, ERP-rejected orders, incompatible statuses, and partial reversals. These are normal commerce operations, not exotic edge cases, and treating them as first-class scenarios stops support requirements from surfacing only after launch traffic arrives.

Use the third slice to prove release and rollback. On Adobe Commerce Cloud that means knowing which queue consumers can be paused, which jobs can drain, which messages can be replayed, what must be reconciled, and which storefront behavior can continue during a deploy or degraded service. A launch plan without recovery evidence is only a deployment schedule.

Quality evidence to collect

Contract and unit tests are useful but do not prove a flow can be operated. Keep a short evidence pack per critical flow: sample payloads, mapping decisions, schema versions, alert examples, runbook steps, reconciliation reports, and the expected business status after success or failure.

Add the ownership answers. If a product fails validation, who corrects it? If an order is accepted by middleware but rejected by the ERP, who decides to retry or repair? If a refund completes in the gateway but never posts to finance, who owns reconciliation? Settling these before launch is what makes support cheap.

Operating model after launch

Run a weekly operational review until the flow is stable: failure count, time to recovery, stale records, manual interventions, mapping changes, and open ownership questions. The first month is not just hypercare; it is where the permanent operating model gets proven against real data.

Chair it with the people who can act: commerce architect, Adobe technical lead, ERP owner, PIM owner, and operations lead. If the dashboard shows failures but nobody can name the business effect, the monitoring is too technical. If the team can name the effect but cannot trace it to a payload, job, or message, the observability is too shallow.

How this connects to the wider CCI map

Use this guide as input to an architecture review and our integration services. If you are pairing Adobe Commerce with a specific ERP, the Adobe Commerce and Dynamics 365 playbook applies the same model end to end. The review turns these decisions into a route map, sequence, and risk register grounded in operating evidence rather than vendor preference.

Practical checklist

• Define source of truth and sync direction for every object.
• Confirm required fields, identifiers, transformations, and validation rules.
• Decide which flows need real time, near real time, scheduled, or batch sync.
• Document API limits, authentication, rate limits, environments, and release windows.
• Build retry, idempotency, duplicate detection, and dead-letter handling.
• Create monitoring, alerts, dashboards, and runbooks before go-live.
• Test business exceptions, not only successful transactions.
• Assign owners for every production failure mode.

FAQs

REST, GraphQL, or the message queue for Adobe Commerce?

Use synchronous REST or GraphQL for narrow customer-facing reads and writes, async or bulk REST for high-volume catalog and inventory loads, and the RabbitMQ message queue for durable, retryable flows like order export. The right surface depends on latency, volume, and who owns recovery, so pick it per flow rather than once for everything.

Should all Adobe Commerce integrations be real time?

No. Checkout-blocking flows such as price and availability need real-time or event-driven updates, while enrichment, reporting, and most catalog loads can run on a schedule. Forcing everything into real time raises cost and undermines reliability.

How do we reduce Adobe Commerce integration technical debt?

Document ownership, payloads, mappings, retries, alerts, and runbooks first. Then retire duplicate cron jobs, replace hidden scripts and one-off SQL, and deliver improvements in controlled slices instead of one large rewrite.

Related pages

• Adobe Commerce platform
• Adobe Commerce and Dynamics 365 playbook
• Data ownership model for commerce integrations
• Direct API vs iPaaS vs middleware
• ERP integrations
• Middleware and iPaaS

Turn the guide into your architecture map.

CCI can review your current commerce stack and produce a practical integration roadmap with owners, patterns, risks, and delivery slices.

Book discovery · See how we work