ERP Integration with Adobe Commerce: SAP, Oracle, and Microsoft Dynamics

Most of the enterprise ecommerce projects that reach WolfSellers do not fail on the frontend. They fail — or slip by months — on the ERP integration. It is the piece that project plans most consistently underestimate, the one with the most external dependencies, the one involving teams that do not report to marketing or digital, and the only one whose failure shows up immediately in daily operations: a customer buys something that does not exist in the warehouse, an order is processed at the wrong price list, an invoice never gets stamped, a credit balance is miscalculated.

The underlying reason is that an ERP integration is not a technical project about connecting two APIs. It is a data governance exercise: deciding, entity by entity, which system is in charge. When that decision is not made explicitly at the start, it gets made implicitly later — and inconsistently — in every endpoint someone writes. The result is the pattern we have seen again and again when rescuing stalled projects: two systems writing the same field at each other, with no referee, until nobody knows which one holds the correct value.

Adobe Commerce (formerly Magento) is, in enterprise architectures, a system of engagement: the place where the customer discovers, configures, quotes, and buys. The ERP — SAP, Oracle, or Microsoft Dynamics 365 in the vast majority of mid-sized and large companies in Mexico — is the system of record: where the accounting, tax, and logistics truth of the business lives. This article is the technical and methodological guide to connecting them: which flows exist, which integration patterns suit each case, what each ERP family implies, how Mexican electronic invoicing shapes the entire architecture, and which mistakes repeat in nearly every project.

This is not a vertical article or a feature article. For the industry angle, we have written about B2B ecommerce in manufacturing and industry; for what Adobe Commerce B2B offers out of the box, we cover it in Adobe Commerce B2B capabilities and features. Here we talk about the integration itself.

---

System of record vs. system of engagement: why the distinction matters

A system of record is the authority over a set of data: if there is a conflict, it wins. A system of engagement is where users operate on that data, typically against a local copy optimized for fast reads.

The ERP is the system of record for inventory, costs, contracted prices, credit limits, legal entities, and accounting documents. Adobe Commerce is the system of engagement: it exposes that state to the buyer, captures intent, and turns it into a transaction the ERP will later recognize as its own.

Confusing the two roles produces two symmetrical errors, both expensive:

• Treating Adobe Commerce as the system of record for data it does not own. The classic example: letting an administrator edit stock in the Adobe Commerce admin panel when stock is governed by the ERP. On the next sync cycle the change is overwritten, someone does it again, and the team concludes that "the integration is broken."
• Treating the ERP as a system of engagement, querying it live on every pageview to render price and availability. The ERP was never designed for the load pattern of a public catalog: latency spikes, and when the ERP enters month-end close or a maintenance window, the site goes down with it.

The source-of-truth table

The first deliverable of any ERP integration project at WolfSellers is not a diagram: it is this table, agreed and signed off by the ERP owner and the digital channel owner before a line of code is written.

When this table exists, 80% of design arguments resolve themselves. When it does not, they get resolved in production.

---

The canonical integration flows

Every Adobe Commerce–ERP integration is built from a subset of these flows. Not all of them are required on day one — in fact we explicitly recommend that they are not, see the phasing section — but it is worth mapping them all during design, so that nobody discovers a missing data channel halfway through the project.

Notes on the flows people most often get wrong

Inventory. The frequent mistake is pushing the full catalog every fifteen minutes. With twenty thousand SKUs and several warehouses that is a heavy job that adds nothing: the vast majority of SKUs did not change. Sending deltas — only what moved since the last cut — reduces the volume by one or two orders of magnitude. In Adobe Commerce, multi-warehouse inventory is modeled with sources and stocks (MSI): sources map to the ERP's warehouses, and the aggregated stock is what the buyer sees as salable quantity. The reservations Adobe Commerce creates on order confirmation are local and transient: they exist to prevent overselling between two sync cycles, and they are released when the ERP confirms fulfillment.

Customer-specific pricing. In B2B it is common for each account to have its own terms. Precomputing the cartesian product of customers by SKU is viable with hundreds of customers and tens of thousands of SKUs, and stops being viable as those numbers grow. The alternative is resolving price on demand — on the product page or when building the cart — with a call to the ERP or the middleware, caching the result per session with a short TTL. The choice between precomputing and resolving live is one of the decisions that most affects site performance, and it must be made with the client's real volumes on the table.

Sales order. This is the only flow where losing a message means losing money. It must be asynchronous, queued, with retries and an idempotency key — typically the order increment ID — so that a retry does not create a second order in the ERP. And it needs a dead-letter queue with alerting: a stuck order has to be visible to a human within minutes, not discovered at month-end close.

---

The four integration patterns

Almost every Adobe Commerce–ERP architecture we have built falls into one of four patterns, or a combination of them. The choice is not ideological: it depends on the number of flows, the volume, the ERP version, and — something almost nobody weighs at the start — who will be operating the integration three years from now.

1. Point to point over REST APIs

The most direct pattern: the connector talks to Adobe Commerce's REST APIs on one side and the ERP's on the other. Mapping, transformation, and retry logic lives in custom code, either as an Adobe Commerce module or — preferably — outside the monolith.

In Adobe Commerce, the modern approach here is out-of-process extensibility: instead of putting the integration inside the store's codebase, it runs in external services that consume the platform's REST and GraphQL APIs and react to its events. Adobe pushes explicitly in that direction with App Builder and its eventing model, and the practical reason is compelling: an integration that lives outside the monolith does not break with every platform upgrade, nor does it compete for web server resources during a traffic spike.

• Advantages: lower initial cost, no additional licensing, full control over the logic, short time to start.
• Disadvantages: observability has to be built from scratch; every new flow adds custom code; knowledge tends to concentrate in a few people; with N systems the number of connections to maintain grows fast.
• When we choose it: projects with a modern ERP, a handful of well-defined flows, and a team that will stay close to the system.

2. Middleware / integration layer (iPaaS)

A middleware — MuleSoft, Dell Boomi, Azure Integration Services, SAP Integration Suite, Oracle Integration Cloud, or even a well-built in-house integration layer — sits between Adobe Commerce and the ERP, and usually between every other system in the business.

Its real value is operational rather than technical: a single place to see which messages went through, which failed, and why; a single retry policy; declarative transformations instead of scattered code; and the ability to change one end — migrating from one ERP version to another, adding a second sales channel — without rewriting the other.

• Advantages: centralized traceability and monitoring, flow reuse across channels, genuine decoupling between ends, easier governance when several teams are involved.
• Disadvantages: licensing and platform cost, learning curve, one more component to operate that can become a bottleneck if too much business logic is pushed into it.
• When we choose it: when ecommerce is not the ERP's only consumer, when there are multiple brands, countries, or channels, or when the client already runs a corporate iPaaS — in that case, debating the pattern means debating a decision already made, and the sensible move is to leverage it.

3. Event-driven integration with queues and messaging

Instead of one system periodically asking "did anything change?", the system that changes publishes an event and interested parties react. It is the pattern that scales best and tolerates failure best, because the queue acts as a buffer: if the consumer is down, messages wait.

Adobe Commerce ships with asynchronous messaging — it uses a message queue for heavy processes and exposes asynchronous and bulk endpoints that return immediately and process in the background — and it can emit events toward external services. On the ERP side, modern platforms also publish business events: SAP through its eventing capability and messaging bus, Dynamics 365 Finance & Operations through business events, and practically every cloud ERP through some webhook mechanism.

• Advantages: low latency without polling, resilience against outages, temporal decoupling between producer and consumer, natural horizontal scale.
• Disadvantages: it demands design discipline — message ordering, duplicate delivery, mandatory idempotency — and teams able to debug an asynchronous flow, which is harder than debugging a synchronous call.
• When we choose it: for inventory and order statuses in high-volume operations, and whenever an order cannot be lost under any circumstance.

4. Batch / file

Still alive, and still the right answer in more cases than the industry admits. A heavily customized ERP, or an older version with no exposed services, can often only produce a file in a nightly window. And for certain data that is perfectly sufficient: an item master that changes twice a week does not need events.

• Advantages: simple, cheap, robust, supported by any ERP regardless of age, optimal for very large volumes.
• Disadvantages: hours of latency, reprocessing a file with errors is awkward, and the nightly window becomes a scarce resource when several processes compete for it.
• When we choose it: initial catalog load, low-volatility masters, nightly reconciliation, and as a temporary bridge while the ERP is modernized.

How to choose without over-designing

Our practical recommendation at WolfSellers: start with the simplest pattern that solves the critical flows, but structure the code from day one as if middleware were coming. That means isolating data mapping, not coupling business logic to a specific HTTP client, and queuing everything that writes. That design makes a later migration from point to point to iPaaS a bounded refactor rather than a rewrite. The opposite mistake — buying an iPaaS for two flows — is just as costly, only the cost is paid in licensing and time to start.

---

What each ERP family implies: SAP, Oracle, and Microsoft Dynamics

This section does not compare which ERP is better. That is a company decision, made for reasons that predate the ecommerce project and are rarely revisited because of it. What matters for integration architecture is what connecting to each one implies: which interfaces it exposes, how they behave, and what known traps each family has.

SAP: S/4HANA and ECC

SAP is the most frequent ERP among large manufacturing, distribution, and consumer goods companies in Mexico, and it is also the one with the widest gap between generations.

• S/4HANA exposes a broad catalog of OData services (v2 and v4) for practically every relevant business object: material, business partner, pricing conditions, sales order, billing document. It is the preferred route and the best documented one. Complementarily, SAP can publish business events to notify changes without polling.
• ECC, the previous generation still running in a great many companies, is integrated mainly through BAPI/RFC and IDoc. IDocs are a mature, reliable message format — with standard types for material master, customer master, and orders — but they are asynchronous by nature and their monitoring lives inside SAP, which complicates observability from the digital channel side.
• What to anticipate: SAP tends to be heavily customized. The fields the business considers "the price" or "the stock" are often not the standard fields but Z-fields added by an earlier project. The discovery session with the functional SAP team is the highest-return activity in the whole project, and it should happen before estimating anything.
• Price determination: SAP resolves price through a condition chain that can depend on customer, material, volume, date, campaign, and customer hierarchy simultaneously. Replicating that logic inside Adobe Commerce is tempting and almost always a mistake: when the business changes a condition in SAP, the copy in the digital channel goes stale. It is far better to ask SAP for the price — precomputed per list or resolved live — than to reimplement its engine.

Oracle: NetSuite and Oracle Fusion / EBS

Very different products live under the Oracle brand, and treating them as one is a classic source of scoping misunderstandings.

• NetSuite is a cloud ERP aimed at mid-sized companies, integrated through SuiteTalk (SOAP and REST web services), RESTlets (custom endpoints written in SuiteScript), and SQL-style queries over its records. It is comfortable to integrate and very flexible, but it enforces governance limits: each script consumes units from a bounded budget, and a poorly designed integration — one that reads too much or works one record at a time — hits that ceiling. Designing for batch operations is not an optional optimization in NetSuite: it is a requirement.
• Oracle Fusion Cloud ERP exposes REST APIs for business objects and file-based bulk import mechanisms for large volumes, plus its own integration layer. The usual combination is REST for online transactional traffic and bulk loading for masters and initial loads.
• Oracle E-Business Suite (EBS), the on-premise generation, is integrated through services exposed from its integration layer, stored procedures, and interface tables. It is more artisanal and resembles the batch world more than the API world.
• What to anticipate: with Oracle it is especially important to settle the customer data model early. The distinction between the legal entity, the commercial account, and the ship-to address has direct implications for how company accounts are modeled in Adobe Commerce B2B, and redoing it after you have live accounts is painful.

Microsoft Dynamics 365: Business Central and Finance & Operations

Here too there are two distinct products under one umbrella, aimed at different company profiles.

• Business Central is the option for mid-sized companies. It exposes OData v4 APIs over its standard entities, allows publishing custom entities from extensions, and connects naturally to the Microsoft automation ecosystem. For many mid-sized projects it is among the most comfortable ERPs to integrate.
• Finance & Operations targets the large enterprise. It integrates through OData entities, custom services, a data management framework for recurring bulk loads, and business events for reactive change notification. In addition, the Dataverse integration exposes data to the Power Platform ecosystem, which sometimes resolves back-office needs without touching the digital channel at all.
• What to anticipate: volumes. OData entities are convenient for transactional traffic but are not the right vehicle for moving hundreds of thousands of records; the bulk mechanism exists for that. Mixing the two paths — or attempting bulk over OData — is one of the most common causes of projects that work in QA and collapse in production.

What all three have in common

---

CFDI 4.0 and SAT stamping: why e-invoicing defines the architecture in Mexico

This is where an integration designed in another country breaks when it lands in Mexico, and where we most often find architectures that have to be redone. Mexican electronic invoicing is not a last-mile detail of the project: it is a constraint that shapes the checkout data model, the order status sequence, and the very definition of which system issues which document.

What CFDI is and who issues it

The CFDI (Comprobante Fiscal Digital por Internet) is Mexico's mandatory electronic invoicing standard, administered by the tax authority, the SAT. Its current version is 4.0, mandatory since 2023 after several extensions. A CFDI is not a PDF: it is an XML file with a structure defined by the SAT that must be stamped by an authorized certification provider (PAC) before it has any fiscal validity. Stamping returns a UUID, or fiscal folio, that uniquely identifies the document.

The architectural question is which system triggers that stamping. Our answer, barring well-justified exceptions, is the ERP, for four concrete reasons:

1. The invoice is an accounting entry, not an artifact of the sales channel. It belongs where revenue, taxes, and receivables are recorded.
2. The fiscal folio must be unique and non-repeating across the entire company. If ecommerce stamps on its own, the company ends up with two sources of folios that need reconciling — exactly the kind of manual work the project set out to eliminate.
3. Ecommerce is not the only channel. Counter sales, telesales, distributors, and marketplaces all invoice through the ERP. Pulling the digital channel out of that circuit turns it into a permanent exception.
4. Cancellation and substitution of documents require fine-grained control: cancellation reason, the document that replaces the original, and in several cases the recipient's acceptance. That workflow belongs to the tax team, which works in the ERP.

The reasonable exception is high-volume pure B2C invoiced to the general public, where a specialized stamping service is sometimes connected directly to the channel — typically with a self-invoicing portal — and the ERP receives the summary. Even there, the design criterion is that there be a single issuer per transaction type, never two competing.

What the digital channel must capture and validate

Even though it does not issue the document, Adobe Commerce is responsible for correctly capturing tax data, because a badly captured field turns into a rejected stamping hours later, when the customer has already left.

CFDI 4.0 tightened validation of the recipient's data. In practice, the checkout must capture and — where possible — validate:

• The recipient's RFC (Mexican tax ID), with the correct structure depending on whether it is an individual or a legal entity.
• Name or corporate name exactly as it appears on the taxpayer's official SAT status certificate. This is the field that generates the most rejections: variations in punctuation, abbreviations, or the corporate suffix cause stamping to fail.
• The recipient's tax regime.
• The postal code of the fiscal address, which does not necessarily match the delivery address.
• The CFDI use code, chosen by the buyer, which must be compatible with their tax regime.
• Payment form and payment method, which determine whether the transaction is invoiced as a single payment or as an installment or deferred payment.

For sales to the general public there is a generic tax ID with its own rules. It is worth modeling that case explicitly rather than treating it as an exception, because in B2C it is usually the majority of transactions.

The payment complement, the detail almost always discovered late

When a transaction is invoiced as an installment or deferred payment — the normal case in B2B on credit — the initial invoice does not close the cycle. Each payment received must be documented with a payment complement (an electronic payment receipt) that references the original document.

This has a direct architectural consequence: the fiscal cycle of a B2B order does not end when the order is delivered, but when it is collected, and that can happen weeks later. The digital channel must reflect that reality if the customer expects to see their account statement in the portal: syncing invoices is not enough, payment applications have to be synced as well. This is one of the flows we most often see left out of the initial scope and enter as a change request mid-project.

Returns and credit notes

A return in the digital channel normally originates as a return request (RMA) in Adobe Commerce. But the fiscal document that reflects it — the credit note, an outflow-type CFDI referencing the original document — is issued by the ERP. The correct design separates the two planes: the authorization flow, reverse logistics, and refund can live in the digital channel or be orchestrated in the OMS, while document issuance and its relationship to the original stay on the ERP side.

It is also worth deciding upfront what happens with cancellations outside the allowed window, partial returns, and returns arriving after month-end close. These are real edge cases that show up in the first week of operation.

What all of this implies for the design

When the business also moves goods across the country with its own or contracted transport, additional documentation requirements for the shipment come into play, and they should be reviewed with the tax team during discovery, because they affect the logistics flow and not only the accounting one.

---

Performance and resilience: the integration must not take the site down

A well-designed integration is invisible when it works and degrades with dignity when it does not. These are the principles we apply across our implementation projects.

Rule one: never query the ERP on every pageview

It is the most important rule and the most frequently broken. Querying the ERP live to render price and availability on a product page means that:

• Your site's latency becomes the ERP's latency, over which you have no control.
• Full-page caching stops helping, because every render depends on an external call.
• A traffic spike — a campaign, El Buen Fin, a mass email — turns into a denial-of-service attack against your own ERP.
• An ERP maintenance window turns into a sales channel outage.

The correct discipline is to project the ERP's state inside Adobe Commerce and refresh it by sync or by event. The buyer reads from the local projection, which responds in milliseconds.

Where live queries are worth it

There are three moments where a synchronous call is justified because the cost of stale data exceeds the cost of latency, and where call volume is bounded by definition:

1. Availability verification at order confirmation, not before. That is one call per order, not one per visit.
2. Available credit lookup at B2B checkout, because authorizing an order against a stale balance is a collections problem, not an experience one.
3. Contracted price for a specific customer in catalogs too large to precompute, cached per session with a short TTL.

Even in these cases, the call needs an aggressive timeout and defined failure behavior: if the ERP does not respond in time, the system must have a planned answer — accept the order and flag it for review, or block with a clear message — but never hang waiting.

Caching with intent

Not all information expires at the same rate. A scheme that works well in practice:

• List price: long cache, invalidated by event when the ERP publishes a change.
• Inventory: short cache (minutes) with thresholds. A SKU with a thousand units does not need second-level precision; one with three units does, and there it is worth lowering the TTL or flagging the product as constrained availability.
• Credit and balance: per-session and very short cache, or no cache at all at the checkout moment.
• Order status: refreshed by event, with a periodic fallback in case an event was lost.

Idempotency, retries, and queues

Every write message toward the ERP must be idempotent: processing it twice must produce the same result as processing it once. Without this, any retry — and there will be retries — duplicates orders. The usual approach is to send a stable key with every message and have the receiver use it to detect duplicates.

Retries should use exponential backoff with jitter, not a tight loop: if the ERP is saturated, retrying every second makes it worse. And they need a limit, after which the message goes to a dead-letter queue with active alerting. An order that never reached the ERP must generate a notification, not wait for someone to notice.

It is worth adding a circuit breaker: when the ERP accumulates failures, stop trying for a period and queue instead of hammering a system that is down. The channel keeps selling, messages accumulate, and when the ERP comes back the queue drains on its own. That is exactly the difference between an ERP maintenance window nobody notices and one that ends up in the incident report.

Reconciliation and drift detection

Even with all of the above done well, systems drift apart. A message gets lost, a manual change slips through, a deployment interrupts a cycle. That is why we always include a nightly reconciliation process that compares both sides — counts per entity, checksums, samples of prices and stock — and reports the differences.

The goal is not for the process to fix them automatically, at least not initially: it is to make them visible before the business sees them. The difference between a team that finds a discrepancy in the 7 a.m. report and one that finds it because a customer complained is enormous, and it is built with a reconciliation job and a dashboard.

Closing the loop, integration observability needs its own metrics: messages processed and failed per flow, latency per call, data age in each projection, and queue depth. If a flow stops, time to detection should be measured in minutes.

---

Project sequence: what to integrate first

The most common sequencing mistake is trying to integrate everything before the first go-live. It produces long projects with no real feedback and all the risk debt concentrated on a single date. Our recommendation is the opposite: the first go-live should include the minimum set of flows that make real selling possible, and everything else enters incrementally with the site already in production.

These durations are indicative and depend above all on two variables the ecommerce team does not control: ERP team availability and the degree of ERP customization. On projects where the functional SAP or Oracle team had dedicated capacity from discovery onward, we have seen phases complete in half the time they take when that team participates on demand.

A note on B2C versus B2B: in pure B2C, phases 1 through 3 usually suffice for a complete operation. Phase 4 is what separates a B2B project from a B2C one, and it is also the longest, because credit and contract pricing touch each company's most idiosyncratic commercial rules. If the project is B2B, it should not be underestimated or left to the end of the budget.

---

Common mistakes in ERP integrations

This table summarizes what we have repeatedly found when auditing existing integrations and rescuing stalled projects.

---

WolfSellers and ERP integrations in Mexico

At WolfSellers we are an Adobe Gold Partner with more than a decade implementing Adobe Commerce and Adobe Experience Cloud in Mexico and LATAM, and back-office integration is one of our core practices. We have designed and built Adobe Commerce–ERP integrations in manufacturing, distribution, and retail, across the three families covered in this article, in both point-to-point architectures and on top of corporate middleware.

What that experience contributes is not primarily code: it is judgment on the decisions made in the first few weeks that are expensive to reverse later. Which flows belong in phase one and which can wait. When an iPaaS pays for itself and when it is over-engineering. How to model the account hierarchy when the ERP and the business do not see it the same way. And how to fit Mexican fiscal reality — CFDI, payment complements, cancellations — into a data model that also has to work for the buyer.

Our starting point is never to propose an architecture. It is to understand the business and the ERP as it stands today, not as it is documented: which version is running and how customized is it? Which interfaces already exist and who maintains them? Is there a corporate middleware the ecommerce channel should lean on? Is the operation B2B on credit, B2C, or both on the same platform? Who stamps invoices today and how are cancellations handled? Which ERP-side team will be available and with how much dedication? The answers determine the pattern, the phase order, and a realistic scope for the first go-live.

If you are evaluating an Adobe Commerce–ERP integration, rescuing an existing one that will not stabilize, or sizing a project before committing budget, we invite you to start with a free discovery with our team. Our ERP integration, custom development, and consulting services cover everything from architecture design to ongoing operation of the flows.

---

Frequently asked questions about ERP integration with Adobe Commerce

How long does an ERP integration with Adobe Commerce take?

It depends on scope and, above all, on two variables usually outside the ecommerce team's control: how customized the ERP is and how much dedicated capacity its maintenance team has. As a reference from our projects, a bounded integration — catalog, inventory, list price, and sales order, which is the minimum for real selling — typically takes 8 to 14 weeks from discovery, including testing. Adding the full fiscal block (CFDI, payment complements, credit notes) typically adds 2 to 5 weeks. A complete B2B scope, with account creation, contract pricing, and live credit validation, brings the total into a 5 to 8 month range. We always recommend phasing: going live with the critical flows and adding the rest with the site already running generates returns sooner and reduces the risk concentrated on a single go-live date.

Middleware or point to point: which one should we choose?

The practical rule we use: if ecommerce is the only system that needs to talk to the ERP and the flows are few and stable, point to point is faster and cheaper, and there is no reason to add another component. If several systems are involved — ERP, PIM, OMS, CRM, WMS — or there are multiple brands, countries, or sales channels, or the company already operates a corporate iPaaS, middleware justifies itself: its value lies in centralized traceability, flow reuse, and decoupling between ends, which is what lets you change ERP versions without rewriting the channel. In either case our recommendation is to structure the code as if middleware were coming — isolated mappings, queued writes, no business logic coupled to the HTTP client — so that a later migration, if it happens, is a bounded refactor rather than a rewrite.

Who should issue the CFDI: the ERP or the ecommerce platform?

In the vast majority of cases, the ERP. The invoice is an accounting and fiscal document that belongs where revenue, taxes, and receivables are recorded; the fiscal folio must be unique across the entire company; ecommerce is not the only channel that invoices (counter sales, telesales, and distributors do too); and cancellation and substitution flows, with their reason codes and their link to the replaced document, belong to the tax team. Having ecommerce stamp on its own creates a second source of folios that must be reconciled. The reasonable exception is high-volume B2C invoiced to the general public, where a stamping service is sometimes connected to the channel — usually with a self-invoicing portal — and the ERP receives the summary. The design criterion in any scenario is that there be a single issuer per transaction type: the problem is not where stamping happens, but stamping happening in two places.

How often should inventory sync between the ERP and Adobe Commerce?

For most operations, a 5 to 15 minute cycle with delta pushes — only what changed — is sufficient and avoids loading both systems unnecessarily. If the ERP can emit stock-change events, better still: latency drops to seconds with no polling. What we do not recommend in any scenario is querying the ERP live on every product view: it destroys page caching, ties site latency to ERP latency, and turns any traffic spike into a back-office problem. The correct pattern is to project stock inside Adobe Commerce with local reservations that prevent overselling between cycles, and perform a live check only at order confirmation, which is one call per order rather than one per visit. For SKUs with very low inventory, it is also worth shortening the TTL or flagging them as constrained availability.

Can Adobe Commerce integrate with a legacy ERP that has no REST APIs?

Yes, and it is more common than it seems. Legacy ERPs usually offer some combination of file exchange over SFTP, proprietary messaging, remote function calls, stored procedures, or interface tables. The usual design in these cases is hybrid: batch for low-volatility masters (items, price lists, customers), which tolerate hours of latency with no business impact, and an intermediate layer that exposes modern services toward Adobe Commerce for transactional traffic — orders, credit lookup, status — translating into whatever mechanism the ERP does support. That intermediate layer can be an iPaaS or a purpose-built service; what matters is that it exists, so the digital channel is not coupled to the ERP's formats and an eventual ERP modernization does not force a rewrite of the ecommerce platform.

What happens to orders if the ERP goes down?

With a well-designed architecture, nothing visible to the buyer: they keep shopping. The condition is that the order write toward the ERP be asynchronous and queued. Adobe Commerce accepts the order, charges if applicable, and enqueues the message; if the ERP does not respond, the message waits and is retried with exponential backoff. When the ERP returns, the queue drains on its own and the orders land in sequence. The three complements that make this actually work are: idempotency, so retries do not duplicate orders; a dead-letter queue with alerting, so a stuck order is visible to a human within minutes; and a circuit breaker that stops hammering the ERP once failures accumulate. What does degrade during an outage are the live lookups — available credit, final stock verification — and for those the policy must be defined in advance: accept the order and flag it for manual review, or block with a clear message. What must never happen is a checkout hanging on a response that is not coming.

---

Related services