Adobe Commerce integration: four jobs and the right API for each

An Adobe Commerce integration is a connection between your store and a system that owns something the store does not: an ERP, a CRM, an order management system, a PIM, a reviews platform, a tax engine. Almost all of them are one of four jobs.

1. ERP and order sync. Orders go out, stock and prices come back.
2. An external handoff. A cart or an order leaves the store, a system somewhere else makes a decision on it, and the finished order comes back.
3. A third-party service connector. You bolt on something you did not build.
4. Catalog and pricing feeds. Product data flows in on a schedule.

Pick the job first, then pick the API. That order matters, and it is where most Adobe Commerce integrations go wrong. The platform hands you REST, GraphQL, asynchronous endpoints, message queues, webhooks and events, and choosing the wrong one is how an integration ends up slow, fragile, or wired straight into checkout where a bad afternoon at the vendor becomes a bad afternoon at your store.

This guide applies to Magento Open Source, Adobe Commerce and Mage-OS, versions 2.4.6 through 2.4.9. If the integration is one piece of a larger project, Adobe Commerce development services walks through the entire engagement.

Which integration job are you actually doing?

Start here. The job decides the mechanism, and the mechanism decides most of what the build will cost you in complexity later.

The rule underneath the table: anything a shopper is waiting on must be fast or must be optional. Everything else belongs in a queue.

What is the Adobe Commerce integration framework?

There is no single product called that. When people search for it they usually mean one of three things: the layered architecture that decides where your code is allowed to plug in, the Web API layer (REST, SOAP and GraphQL) that external systems talk to, or Adobe's integration starter kit for App Builder. All three are covered below. The architecture is the one worth understanding first, because it explains why some integrations are a two-day job and others fight you for a month.

The four-layer architecture

Adobe Commerce follows a structured approach with four primary layers:

1. Presentation Layer - The topmost layer handling user interaction through controllers and view components (layouts, templates, blocks, CSS, JavaScript). This layer interacts with the service layer and is used primarily by web users and system administrators.
2. Service Layer - Acts as a bridge between presentation and domain layers, implementing service contracts defined through PHP interfaces. This layer enables API access (REST/SOAP) and facilitates the addition or modification of business logic without disrupting the system.
3. Domain Layer - Contains the core business logic independent of database specifics, defining generic data objects and models encapsulating business logic for various data types.
4. Persistence Layer - The bottom layer focusing on resource models responsible for data extraction and modification through CRUD operations, implementing SQL code to fulfill these requests.

The practical version: integrate at the service layer. Service contracts are the interfaces Adobe promises not to break between minor releases, and they are the same interfaces the REST API is built on. Integrations that reach past them into resource models or straight into SQL work fine right up to the upgrade that breaks them, and then you are reading a diff at midnight instead of testing a release.

How do I integrate Adobe Commerce with an ERP?

An ERP integration is a data ownership agreement with an API attached. Before you write a line of code, settle who owns each field:

• Who owns the product price, the ERP or Commerce?
• Who owns stock, and how stale is stale enough to oversell?
• Who owns the customer record and the customer group that drives their pricing?
• Who generates the order number the customer sees on their invoice?

Get that table agreed and the build is mostly plumbing. Skip it and you will spend the project arguing about which system was right, usually while somebody's stock number is wrong on both.

What it looks like when it works: orders reach the ERP without anyone rekeying them, stock is right often enough to trust, and finance stops reconciling two systems by hand.

The order push

The order is the piece people get wrong most often, because it is tempting to call the ERP the moment the order is placed. Do not. The ERP will be slow one day, or down, and a synchronous call in sales_order_place_after turns their outage into your failed checkout.

The pattern that holds up:

1. The order is placed and saved in Commerce. Checkout is done, the customer is gone.
2. An observer publishes the order ID to a queue topic. That takes milliseconds.
3. A consumer picks it up, builds the ERP payload, and posts it.
4. On success, it writes the ERP reference back onto the order. On failure, it throws, so the message is retried rather than lost.

Two habits make this survivable. Make the push idempotent, so sending the same order twice creates one record rather than two, usually by having the ERP key on your order increment ID. And store the sync state on the order so a human can answer "did this one go through" without opening a log file.

If you would rather not build the queue plumbing yourself, Adobe's asynchronous REST endpoints do the same thing at the front door. Post to /async/V1/orders instead of /V1/orders and Commerce writes the request to the message queue and hands you back a bulk_uuid immediately; the async.operations.all consumer executes it afterwards. You get the decoupling without writing a consumer, at the cost of some control over retries.

What about CRM and OMS?

Same shape, different payload. CRM: the payload is the customer, and the trap is deciding who owns the email address when a shopper changes it at checkout. OMS: the payload is the order after it is placed, so most of the traffic runs the other way, shipments and status coming back in. Both belong in a queue, for the same reason the ERP push does.

The Connector for Magento Order Management System (OMS) acts as an intermediary between Commerce and OMS, handling order creation, inventory updates, and shipment information. Connections like these stay reliable only when the heavy lifting happens asynchronously; we cover how to write a message queue for Adobe Commerce in a separate hands-on guide.

Epicor Prophet 21 and QuickBooks each have their own version of this conversation, written up separately. If you want the field-ownership table as something you can actually fill in, the ERP integration readiness checklist is it.

How do I hand a cart to an outside system for approval and get the order back?

This one comes up more than the platform docs suggest, and it is the job that made us rewrite this guide.

The setup: some buyers are not allowed to complete their own purchases. A B2B brand that sells through an independent reseller network runs into it constantly, and so does anyone selling to schools, hospitals or franchise groups. The buyer builds a cart, but a manager has to approve it before it becomes an order, and the system that owns that approval is not Adobe Commerce.

Adobe Commerce ships company accounts with purchase-order approval rules on the paid tier. Magento Open Source and Mage-OS do not, so on those you build the handoff yourself. Either way, if the approval lives in an external system you are building the handoff.

The shape of it:

1. Flag the account. A customer attribute or a customer group marks the buyer as approval-required. Everything downstream reads that one flag.
2. Change the checkout button. A plugin on the payment step swaps "Continue to Payment" for "Submit for Approval" when the flag is set. The customer never sees a payment form they are not allowed to use.
3. Send the cart out. POST the quote (items, quantities, the customer, the shipping address, the totals you calculated) to the external system, and get an identifier back.
4. Confirm inside Commerce. Redirect to a normal confirmation page on your own store. This detail matters more than it sounds: the moment you bounce the customer to somebody else's UI, they think they have left your site, and half of them stop trusting the order went through.
5. Bring the order back. When the approver signs off, the external system calls your endpoint and the order is created in Commerce with the right customer, group pricing and status.

Four things break here, reliably:

• Prices do not survive the round trip. The cart was priced by Commerce with catalog rules, tier prices and the customer's group. The external system recalculates with its own logic. Decide which one is authoritative and send totals as data, not as a suggestion.
• Promotions do not survive it either. Cart rules that add a free item, or stack conditionally, rarely translate. The usual fix is to narrow what is available to approval-required buyers: hide the promotions that cannot round-trip, and auto-apply the equivalent discount so nobody quietly loses it.
• The return call gets retried. Approvers double-click. Networks time out mid-response. Key the return endpoint on the external reference and make a repeat call return the order you already created instead of a second one.
• Rejection has no path back. If the approver says no, the buyer needs somewhere to go. The cheap version is an email. The good version is a link that restores the cart in Commerce so they can edit and resubmit.

None of this needs the paid tier, and none of it needs a separate ordering portal. It needs one flag, one checkout plugin, two API calls, and an honest decision about who owns the price. The checkout side of it, step by step, is in handing a B2B cart to an outside approver.

What counts as a third-party integration in Adobe Commerce?

Adobe Commerce third-party integrations are connections between your store and a system neither Adobe nor you built: a reviews platform, a PIM, a tax service, a shipping rate provider, a marketing automation tool. There are exactly three ways to get one, and they cost very different amounts over five years: install a marketplace extension, use a connector the vendor maintains, or build a custom API integration.

Adobe Commerce supports integration with countless third-party solutions through:

• Pre-built connectors (like the Icecat connector for product information management)
• Custom API-based integrations
• Marketplace extensions

Yotpo is the usual example: reviews and loyalty, maintained by the vendor, installed rather than built. That is the connector route in one sentence.

Which of the three you pick comes down to one question: who patches it when Adobe ships 2.4.10?

We are not neutral here: we build and maintain custom integrations for a living, and we still tell people to use a good marketplace extension when one exists. Build custom when the connector forces your business to work the vendor's way rather than yours. One case is its own category: if the third party is a payment provider, the module has to live inside Commerce's payment flow rather than beside it, and we wrote up integrating a payment gateway specifically as a separate discipline.

The connectors you do not build

If you are already inside Adobe's stack, Target, Experience Manager, Real-Time CDP and Analytics connect without you writing the connector.

These are Adobe Commerce features, not Magento Open Source ones. If you are on Open Source or Mage-OS, the equivalents are ordinary third-party integrations and you should price them that way.

How do I keep catalog and pricing feeds in sync?

Feeds are the least glamorous job and the one that quietly eats the most engineering time, because the volume is high and the failure is silent. Nobody notices a price feed that stopped three days ago until a customer buys at last quarter's price.

Three things make feeds behave:

Use the bulk asynchronous endpoints. Instead of looping single REST calls, post an array to /async/bulk/V1/products (or the equivalent entity). Commerce accepts the whole batch, splits it into individual queue messages, and returns a bulk_uuid you can check later. One HTTP call for a thousand rows, and none of it blocks anything.

Send deltas, not the whole catalog. A full catalog push every night is the default first attempt and it is almost always wrong. It costs hours of consumer time, reindexes constantly, and hides the small changes that mattered. Timestamp your source and send what changed.

Watch the price scopes. Prices in Adobe Commerce live at website scope, tier prices live per customer group, and special prices have dates. A feed that writes a single default price and calls it done will overwrite B2B pricing across every group on the store, and it will do it silently. This is the single most common feed bug we get called about.

If the catalog data itself is the mess rather than the sync, that is a PIM problem, not an API problem, and B2B catalog data and PIM is where that side lives. Punchout and EDI are their own version of this job if you sell into corporate procurement.

Should I use REST, GraphQL or a message queue?

All three ship with the platform, and they are not competitors. They answer different questions.

REST

The REST API enables integration with Adobe Commerce through a standardized, lightweight approach:

• Supports CRUD operations (Create, Read, Update, Delete) and search functionality
• Provides field filtering to conserve bandwidth
• Enables integration-style calls where multiple services can be called simultaneously
• Authentication through OAuth 1.0a, tokens, or login credentials

REST endpoints follow a structured format and can be accessed through:

https://<server>.api.commerce.adobe.com/<tenant-id>/<endpoint>

For on-premises or cloud deployments, the format differs slightly.

Use REST when another system needs to read or write Commerce data on its own schedule. It is the right default for ERP, OMS, and anything back-office. Add /async to the route when you do not need the answer immediately, and /async/bulk when you are sending many records at once.

GraphQL

GraphQL offers a more flexible and efficient alternative to REST, particularly for frontend development:

• Allows querying for exactly the data needed in a single request
• Reduces over-fetching and under-fetching of data
• Provides strong typing and introspection capabilities
• Supports both GET and POST methods regardless of operation type

A sample GraphQL query might look like:

country(id: "US") {
  id
  full_name_english
}
categories(filters: {name: {match: "Tops"}}) {
  items {
    name
    products(pageSize: 10, currentPage: 2) {
      items {
        sku
      }
    }
  }
}

Use GraphQL when something is rendering a screen: a headless storefront, a PWA, a mobile app. It is built around the shopper's session, so it covers catalog, cart, checkout and customer well, and back-office entities barely at all. Do not plan an ERP integration on GraphQL. That is not what it is for.

Message queues

Use a queue when the work is slow, high volume, or must not fail quietly. The queue is what stands between your checkout and somebody else's downtime, and it gives you retries for free. The full setup is in our Adobe Commerce message queue guide.

Webhooks and events

Two more options worth knowing. Webhooks are synchronous: Adobe Commerce calls your endpoint and waits for the answer, which is what you want when Commerce genuinely needs an external verdict mid-flow, like a credit check or an out-of-band stock validation. Because they block, a webhook can also interrupt the operation, and because they block, every one of them needs a timeout and a decision about what happens when the vendor does not answer. Events are the opposite: Commerce tells another system something happened and moves on. If nothing in Commerce depends on the reply, use events, not a webhook.

How do I authenticate an Adobe Commerce API integration?

Adobe Commerce supports several authentication approaches for API access:

1. OAuth 2.0 - An open standard for secure authorization that allows applications to access resources without exposing user credentials. Benefits include improved security, better user experience, and support for token expiration.
2. OAuth 1.0a - Used by third-party applications for authentication.
3. Token-based Authentication - Primarily used for mobile applications.
4. Login Credentials - Used by administrators and customers.

For Adobe Commerce as a Cloud Service, authentication relies on Adobe Identity Management Service (IMS) to secure API requests.

To define a new integration in Adobe Commerce:

1. Navigate to System > Extensions > Integrations in the admin panel
2. Click "Add New Integration"
3. Provide the integration name and contact information
4. Enter the callback URL and identity link URL (using HTTPS is strongly recommended)
5. Define resource access levels (All or Custom)
6. Save the integration and authorize it when prompted

After setting up and authorizing the integration, the system will provide the necessary credentials for API access.

One line on that step 5: choose Custom, not All. Nearly every integration we audit has at least one set of credentials with full admin API access because "All" was faster on setup day. Scope each integration to the resources it uses, and the day one of those vendors gets breached becomes an inconvenience instead of an incident.

What is the Adobe Commerce integration starter kit?

The Adobe Commerce integration starter kit expedites setup for back-office integrations:

1. Create Your Project:
   • Log in to Adobe Developer Console
   • Create a new project from template (App Builder)
   • Add required API services
2. Install and Configure:
   • Clone the starter kit repository
   • Install dependencies
   • Configure the connection to your Commerce instance
   • Run the onboarding scripts
3. Customize and Extend:
   • Modify the boilerplate code to match your specific integration needs
   • Test your integration thoroughly
   • Deploy to your production environment

The starter kit follows a standardized architecture with directories for different entities (customers, orders, products) and actions for handling events from both Commerce and external systems.

It provides reference integrations for common commerce data entities: customers, customer groups, orders, products, shipments and stock, with bi-directional synchronization, so changes in Commerce propagate to external systems and vice versa.

Before you start, make sure you have:

1. Access to your Adobe Commerce admin panel
2. Appropriate API credentials and permissions
3. For starter kit usage: an Adobe Developer account with System Administrator or Developer Role permissions
4. Access to App Builder for starter kit deployment

The honest caveat: the starter kit is an Adobe App Builder path. It is a good fit if you are already in the Adobe ecosystem and want your integration code running outside your Commerce instance. If you are on Magento Open Source or Mage-OS, or you would rather the integration ship inside a module you own and can read, the queue-and-REST pattern in this guide gets you to the same place without a second platform to license and learn.

What breaks in Adobe Commerce integrations?

After enough of these, the failures rhyme. In rough order of how often we get the call:

1. A synchronous call to a slow vendor sits inside checkout. Move it to a queue, or bound it with a short timeout and a fallback.
2. A feed silently stopped. Nothing alerts on "zero messages processed," so nobody notices for days. Alert on absence, not just on errors.
3. A retry created a duplicate. The integration was never idempotent. Key on a stable external reference.
4. Credentials had full access. See the note above about Custom versus All.
5. An upgrade broke it. The integration reached past the service layer, or a marketplace extension had not been updated for the new release.

Five habits prevent most of it, one for each:

1. Nothing slow runs inside a shopper's request. Queue it, or give it a timeout and a fallback you have actually tested.
2. Alert on silence, not just on errors. "Zero messages processed since Tuesday" has to reach a human.
3. Key every write on a stable external reference, so a retry updates the record instead of duplicating it.
4. Scope credentials to Custom, expire the tokens, keep it all on HTTPS. Then re-check who still has access twice a year.
5. Integrate at the service layer, and re-test every integration point on each release. That is the entire upgrade story.

Which versions does this apply to?

Everything here works on Magento Open Source, Adobe Commerce and Mage-OS, versions 2.4.6 through 2.4.9. The Web API layer, the message queue framework and the admin Integrations panel have been stable across that whole range.

Two dates worth knowing while you plan. Adobe Commerce and Magento Open Source 2.4.6 left full support on August 11, 2026 and is now in extended support, so an integration project on 2.4.6 should be scoped alongside the upgrade rather than after it. 2.4.9 reached general availability on May 12, 2026 and is the current line. If a version move is on your roadmap anyway, what 2.4.8 means for your business still mostly applies.

What should Adobe Commerce integration services include?

If you are buying this work rather than building it, here is what the scope should cover, and what to push back on if it does not.

• A field-ownership map before any code. Which system is authoritative for price, stock, customer, order number. An agency that skips this is going to bill you for the argument later.
• The mechanism choice, written down. Queue, async REST, bulk, GraphQL, webhook, and why each one. If everything in the proposal is a synchronous REST call, that is a red flag, not a simplification.
• Failure handling as a deliverable. Retries, idempotency, alerting on silence, and a way for a non-developer to answer "did this order sync."
• A staging environment with real-shaped data. Integrations do not fail on the happy path. They fail on the customer with three shipping addresses and a 40 percent tier price.
• Maintenance after launch. Adobe Commerce ships releases. Vendors change their APIs. Somebody has to own the integration in year two, and it is cheaper if that is decided in year zero.

That list is roughly how our Adobe Commerce integration services are structured, and it is also a fair scorecard for anyone else you are talking to.

Where to start

If you are scoping an integration right now, the useful first hour is not spent reading API docs. It is spent writing down which system owns each field, and which of the four jobs you are actually doing. Everything after that is a choice between REST, a queue, and a schedule.

We do this work every week, across ERPs, PIMs, order tools and the occasional system nobody has heard of. If you have got an Adobe Commerce integration that is misbehaving, or one you have been putting off because nobody can agree on who owns the price, tell us what you are dealing with. We like these problems more than is probably normal.