Out-of-process extensibility moves custom logic off the Magento server and into a separate application. Webhooks let Adobe Commerce call that application synchronously and wait for an answer before it continues, while Adobe I/O Events fire asynchronously after the fact. Together they replace fragile core edits with integrations that survive platform upgrades.
What “out-of-process” actually means
For most of Magento 2’s life, customizing the platform meant writing a module that lived inside the codebase. You added plugins, observers, and preferences that ran in the same PHP process as the core, sharing its memory and its deploy cycle. That model is powerful, but it has a cost that every long-running Adobe Commerce store eventually pays: each custom module is a compatibility liability. When Adobe ships an upgrade, your in-process code has to be re-tested against it, and a change to a core class signature can break a plugin that worked for years.
Out-of-process extensibility inverts that arrangement. Instead of running your integration logic inside Magento, you run it as a separate service that Commerce talks to over the network. The core stays close to vanilla, your custom behavior lives in an app you own and deploy independently, and the two communicate through defined interfaces rather than shared code. Adobe’s own guidance frames this as the preferred direction for new integrations, and the out-of-process extensibility documentation lays out the runtime Adobe provides to host these apps.
The payoff is upgrade safety. An external app does not care whether the store is on 2.4.7 or a later patch release, because it depends on a stable event and webhook contract rather than on internal class internals. That is a meaningful reduction in the upgrade tax that makes many merchants delay patching, and delayed patching is a security problem in its own right across the Magento and Adobe Commerce install base.
The three building blocks: events, webhooks, and App Builder
Three pieces make out-of-process extensibility work on Adobe Commerce, and it helps to keep them straight because the names get used loosely.
Adobe I/O Events are asynchronous notifications. Commerce emits an event, for example an order being placed or a customer being saved, and publishes it to Adobe’s event bus. Subscribers receive it after the fact. The originating process does not wait for anyone to handle it. This is the fire-and-forget channel.
Webhooks are synchronous calls. When a configured trigger fires, Commerce makes an HTTP request to an external endpoint and waits for the response before it continues its own work. Because Commerce blocks on the answer, a webhook can influence what happens next: approve or reject a value, enrich a payload, or veto an operation. Adobe’s webhooks documentation describes them as configurable synchronous logic that executes calls to external systems when a Commerce event triggers.
App Builder is where the external code runs. It is a serverless platform on Adobe I/O Runtime, so you deploy functions rather than standing up and maintaining your own servers. The introduction to App Builder positions it as the runtime for building these custom experiences without touching the Commerce core. You do not have to use App Builder as the host, any reachable HTTPS endpoint can answer a webhook, but App Builder is the path Adobe supports end to end.
Webhooks vs Adobe I/O Events: when Commerce needs an answer
The single most useful decision rule is whether Commerce needs a reply before it proceeds. If it does, you want a webhook. If it does not, you want an event. Getting this wrong is the most common design mistake teams make when they first reach for these tools.
Use a webhook when the external system must return a value that shapes the next step:
- Validate an order against a fraud or credit service before it is placed.
- Pull a live tax figure from an external engine at checkout.
- Confirm stock in a warehouse management system before Commerce commits the sale.
- Enforce a business rule that lives in another system, such as a customer-specific credit hold.
Use an Adobe I/O Event when the external system only needs to know something happened and Commerce should not wait:
- Sync a new customer to a CRM or marketing platform.
- Push an order to an ERP or accounting system for downstream processing.
- Notify a data warehouse or analytics pipeline.
- Trigger a fulfillment or notification workflow.
| Dimension | Webhooks | Adobe I/O Events |
|---|---|---|
| Timing | Synchronous, Commerce waits | Asynchronous, fire and forget |
| Can change the outcome | Yes, the response is used | No, notification only |
| Failure impact | Can block the triggering operation | Isolated from the core flow |
| Typical use | Validation, enrichment, veto | Sync, notify, downstream processing |
| Latency sensitivity | High, sits in the request path | Low, runs after the fact |
| Best for | Real-time decisions | Data propagation |
The failure row is the one to sit with. Because a webhook runs inside the request path, a slow or unavailable endpoint can stall the operation that triggered it. That is a feature when a fraud check must pass before an order is accepted, and a hazard when the endpoint is flaky. Events carry the opposite tradeoff: a downstream consumer can be down for an hour and the storefront never notices, but you get no chance to influence the original action.
What a webhook actually does at runtime
A webhook subscription has four parts, and understanding them removes most of the mystery.
First, a trigger. You bind the webhook to a specific Commerce hook point, either a predefined one or a custom event you declare. This is the moment Commerce will pause and call out.
Second, the request. Commerce assembles a payload from the data available at that point and sends it to your configured URL over HTTPS. You control which fields go into the payload, so you send only what the external system needs rather than the entire object graph.
Third, the response contract. Your endpoint returns a structured result that tells Commerce what to do. The response can approve the operation, reject it with a message, or return modified data that Commerce then uses. This is the mechanism that lets an external service veto a checkout or rewrite a value.
Fourth, error and timeout handling. Because the call is synchronous, you have to decide what happens when the endpoint is slow or returns an error. Adobe’s best-practice guidance is to keep webhook handlers fast and defensive, set sensible timeouts, and design the endpoint to fail in a way that matches the business risk. A tax webhook that times out might fall back to a cached rate, while a fraud webhook that times out might hold the order for manual review rather than silently approving it.
Signing and verifying the payload matters here too. Since the endpoint is a public URL, it should verify that a request genuinely came from your Commerce instance before acting on it, and it should never trust the payload as authenticated user input.
Where in-process code still wins
Out-of-process is the right default for integrations, but it is not a universal replacement. Some work belongs inside Magento, and pretending otherwise leads to slow, chatty designs.
Keep logic in-process when it needs synchronous access to Magento’s internal data and object model with no network hop, when it runs on every request and cannot tolerate added latency, or when it manipulates the rendering pipeline directly. Theme logic, layout changes, and storefront behavior are the clearest case: a Hyva frontend runs its interactivity in inline Alpine.js in the browser, not in an external app, and dressing up an existing Luma extension for a modern theme is a front-end compatibility task, which we cover in adapting third-party Magento extensions to Hyva.
Move logic out-of-process when it talks to an external system, when it can be asynchronous, when it changes on a different release cycle than Magento, or when it would otherwise be a fragile core override. Integrations with ERP, CRM, PIM, tax, fraud, and fulfillment systems are the textbook fit, and they are exactly the connections that used to accumulate as brittle in-process modules.
The honest framing is a spectrum, not a binary. A mature Adobe Commerce build in 2026 keeps the storefront and core lean, pushes integrations to external apps, and reserves in-process modules for the handful of cases that genuinely need to run inside the platform.
Which editions and versions support this
This is where teams get tripped up, so it is worth stating plainly. Webhooks and App Builder are Adobe Commerce capabilities, delivered through the out-of-process extensibility modules and the Adobe Developer platform. They are not part of Magento Open Source. Adobe Commerce as a Cloud Service (ACCS) is built around out-of-process extensibility from the ground up, since it does not allow the core code edits that on-premise installs tolerate, so for ACCS this model is not optional, it is the way you extend the platform at all.
Adobe I/O Events sit slightly differently. The eventing modules can run on recent Adobe Commerce, and the Adobe I/O Events for Adobe Commerce connector extends event publishing to compatible installs. If you are planning around this, confirm the exact module versions against your Commerce release rather than assuming, because the extensibility tooling has moved quickly over the last several releases.
The practical read: if you are on Adobe Commerce, whether PaaS on-premise, cloud, or ACCS, out-of-process extensibility is available and is the recommended integration path. If you are on Open Source, you can still integrate through APIs and message queues, but the managed webhook and App Builder tooling is an Adobe Commerce benefit. This is one of the concrete feature differences that shapes an edition decision, and it is the kind of tradeoff our technology partner relationships help us weigh against a merchant’s real integration load.
A migration path off core edits
Most stores that would benefit from this already carry a pile of in-process integration modules. You do not rewrite them all at once. A phased path keeps risk low.
- Inventory the integrations. List every custom module that talks to an external system. These are your out-of-process candidates. Modules that only touch internal data or rendering are not.
- Rank by fragility. The module that breaks on every upgrade, or the one that owns a business-critical connection like tax or fraud, moves first. Stability is the payoff, so start where instability hurts most.
- Pick the channel. For each, decide webhook or event using the answer test above. Validation and enrichment become webhooks, propagation becomes events.
- Build the external app. Stand up the handler, on App Builder or your own infrastructure, and implement the response contract or the event consumer. Make every handler idempotent so a retried call never double-processes.
- Run in parallel, then cut over. Keep the old module live while the external app shadows it, compare outputs, and only remove the in-process code once the external path is proven. Then delete the module and reclaim the upgrade safety.
Done this way, each migration is a small, reversible step, and the codebase gets lighter and more upgrade-safe with every one.
How this changes the storefront and the wider stack
Keeping integrations out-of-process protects the thing merchants care about most: a fast storefront. When a CRM sync or an ERP push runs as an external app reacting to events, it never sits in the request path, so it cannot slow a page. That separation is the same discipline that keeps a Hyva theme fast, and it is why we treat integration architecture and front-end performance as one problem rather than two across our Magento and Hyva builds.
The pattern is not unique to Adobe Commerce either. Event-driven, out-of-process integration is how modern commerce platforms are meant to be extended, and the same architecture underpins the work we do on Shopify and Shopify Plus, BigCommerce, and Shopware storefronts. A team that has internalized the events-and-webhooks model on one platform carries most of that thinking to the next, which is part of the depth we describe on our about page. If you are weighing whether to keep extending Magento with core edits or move to this model, that is a conversation worth having early with Bemeir, because it shapes every integration decision that follows.
FAQ
What is out-of-process extensibility in Adobe Commerce?
Out-of-process extensibility runs custom logic as a separate application outside the Magento codebase, communicating with Commerce through Adobe I/O Events and webhooks rather than in-process modules. Because the external app does not depend on core class internals, it survives platform upgrades far better than a traditional in-process customization, which reduces the upgrade and testing burden that leads many merchants to delay patching.
What is the difference between an Adobe Commerce webhook and an Adobe I/O Event?
A webhook is synchronous: Commerce calls an external endpoint and waits for the response before continuing, so the reply can validate, enrich, or veto the operation. An Adobe I/O Event is asynchronous: Commerce emits a notification and does not wait, which suits data propagation like CRM or ERP sync. Use a webhook when Commerce needs an answer, and an event when it only needs to notify.
Do webhooks work on Magento Open Source?
Webhooks and App Builder are Adobe Commerce capabilities delivered through the out-of-process extensibility modules and the Adobe Developer platform, and are not part of Magento Open Source. Adobe Commerce as a Cloud Service is built around this model. Open Source stores can still integrate through APIs and message queues, but the managed webhook and App Builder tooling is an Adobe Commerce benefit. Confirm module versions against your specific release.
Will out-of-process integrations slow down my storefront?
Events will not, because they run asynchronously outside the request path. Webhooks can, because Commerce waits for the response, so a slow endpoint adds latency to the operation that triggered it. Keep webhook handlers fast, set sensible timeouts, and reserve them for real-time decisions like fraud or tax. Push everything that only needs notification, such as CRM and ERP sync, onto asynchronous events.
Should we migrate our existing custom modules to this model?
Migrate the modules that talk to external systems, especially the ones that break on every upgrade or own critical connections like tax and fraud. Leave modules that only touch internal data or rendering in place. Move one integration at a time, run the external app in parallel with the old module until it is proven, then remove the in-process code to reclaim upgrade safety.
