data-slots=image, heading, text
Commerce Extensibility

Adobe Commerce extensibility

Learn how to create out-of-process extensions for Adobe Commerce using App Builder and App Management.

Extend Adobe Commerce without changing the Commerce core

Adobe Commerce supports out-of-process extensibility: custom business logic, integrations, and user experiences run as applications outside the Commerce application process. These applications communicate with Commerce using supported APIs, events, webhooks, and extension points rather than adding PHP code directly to the Commerce codebase.

Adobe implements this model through Adobe Developer App Builder and Commerce App Management:

This separation lets developers create and deploy an app independently from the Commerce release cycle. It also helps isolate custom workloads, reduce upgrade coupling, and make integrations easier to operate and evolve.

Out-of-process and in-process extensibility

Traditional Commerce extensions use an in-process model. PHP modules, plugins, observers, and other customizations run inside the Commerce application process and interact directly with its runtime, services, and database. This model can provide deep control, but it also couples custom code to the Commerce version, PHP runtime, internal APIs, deployment process, and available application resources.

Out-of-process extensibility moves that custom logic outside the Commerce process:

Characteristic
Out-of-process extensibility
In-process extensibility
Where code runs
Outside Commerce, on App Builder and its supporting services
Inside the Commerce application process
How it connects to Commerce
APIs, events, webhooks, SDKs, and supported extension points
PHP extension points and runtime services
Release lifecycle
Independently developed, tested, deployed, and operated
Coupled to Commerce deployment and upgrades
Upgrade considerations
Custom logic is decoupled from the Commerce codebase
Custom code must remain compatible with Commerce and its runtime
Scaling and resource use
Can scale and process independently of the Commerce application
Shares Commerce application resources
Typical strengths
Upgrade safety, integration flexibility, isolation, and independent delivery
Deep, synchronous control of the Commerce runtime

The two models are not interchangeable implementation details. They represent different lifecycle and operating models. For new Commerce apps and modernizing existing customizations, start with App Management and build using the out-of-process extensibility model.

Build with App Management

Use App Management as the foundation for your Commerce extension lifecycle. It establishes how an app is defined, associated with a Commerce instance, configured, installed, updated, and removed.

Start here to:

  1. Define the app and its Commerce capabilities.
  2. Build the app with App Builder, Commerce SDKs, and supported integration patterns.
  3. Connect the app to Commerce through APIs, events, webhooks, or UI extension points.
  4. Deploy and associate the app with Commerce.
  5. Configure, test, and operate the app across its supported environments. See Observability for monitoring guidance.

When to use a starter kit

Starter kits are opinionated accelerators, not alternate application lifecycle systems. They provide scaffolding, examples, and recommended patterns for common scenarios such as creating an integration and customizing the checkout process.

Choose a starter kit when you want to:

Regardless of whether you start from an empty App Builder project or a starter kit, the resulting application follows the App Management lifecycle.

Build with App Management. Start with a starter kit if you need an accelerator.

What's new

data-src=/_includes/templated/whats-new.md