What is Adobe App Builder?

Adobe Developer App Builder — serverless extensibility for Adobe Commerce and the Experience Cloud.

Sources: Introduction to App Builder (opens in new tab), App Builder docs (opens in new tab)

The old way: in-process extensibility

Traditional Adobe Commerce development runs inside the PHP application:

• Modules, plugins, observers, preferences
• Tied to PHP version, server stack, and upgrade compatibility
• Custom code lives in the Commerce codebase

The new way: out-of-process extensibility

What is App Builder?

A cloud-based, serverless extensibility platform for:

• Building secure, scalable apps that extend Commerce
• Integrating with third-party systems (ERP, OMS, Slack, etc.)
• Creating custom admin and operator experiences

It is a unified framework on Adobe infrastructure — globally distributed and auto-scaling.

Three extensibility use cases

Adobe defines three primary patterns:

1. Middleware extensibility — Connect external systems; build custom connectors or use pre-built integrations
2. Core services extensibility — Extend default behavior with custom business logic
3. User experience extensibility — Custom storefronts, back-office apps, and operator dashboards

Why teams adopt App Builder

• Faster time to launch — decoupled features ship independently of Commerce releases
• Easier upgrades — custom code is outside the Commerce codebase
• Freed server resources — heavy integration logic no longer competes with storefront traffic
• Composable commerce — mix Adobe services with best-of-breed third parties

Architecture at a glance

Core platform components

A typical App Builder project

my-app/
├── app.config.yaml    # Action definitions, bindings
├── .env               # Runtime secrets (never commit)
├── actions/           # Serverless backend (Node.js)
│   ├── commerce/      # Commerce REST / OAuth helpers
│   └── oauth1a.js
├── web-src/           # React UI (optional)
│   └── src/components/
└── test/              # Unit tests

After aio app deploy, actions get a public runtime URL.

Actions: the backend brain

Actions are serverless functions deployed to Adobe I/O Runtime.

• Written in Node.js (JavaScript)
• Use @adobe/aio-sdk for logging and runtime APIs
• Call Commerce via OAuth 1.0a REST (COMMERCE_BASE_URL, consumer key/secret, access tokens)
• Return HTTP responses (statusCode, body)

web-src: when you need a UI

Not every app needs a frontend. Background integrations (inventory sync, event handlers) often use actions only.

When you do need UI:

• web-src/ holds a React app using React Spectrum (Adobe's design system)
• Example: an operator dashboard that lists orders and triggers accept/decline workflows
• Deployed as a static web action alongside backend actions

I/O Events: Commerce → App Builder

Commerce emits events (e.g. observer.sales_order_place_after) configured in io_events.xml.

Flow:

1. Event fires in Commerce
2. Adobe I/O Events routes it to your App Builder action
3. Action processes asynchronously (notify Slack, update ERP, orchestrate payment)

Connecting to Commerce: REST + OAuth

App Builder actions authenticate to Commerce using Integration credentials:

• COMMERCE_BASE_URL
• COMMERCE_CONSUMER_KEY / COMMERCE_CONSUMER_SECRET
• COMMERCE_ACCESS_TOKEN / COMMERCE_ACCESS_TOKEN_SECRET

Actions call REST endpoints: /rest/V1/orders, /rest/V1/products, custom modules, etc.

The golden rule: PHP vs App Builder

From Adobe's split-payment architecture guidance:

If it must run synchronously in the Commerce request cycle, or invoke internal APIs with no clean external surface — keep it in PHP. Everything else can move to App Builder.

Example: synchronous vs async

Checkout threshold ($100 minimum) — must block the customer before Place Order:

Customer → [CheckoutPlugin in PHP] → blocks immediately
         → (if bypassed) → Order placed → I/O Event → App Builder audit

Commerce owns the user-facing guard; App Builder owns the post-placement audit.

Example: store credit stays in PHP

Store credit must be applied while the cart is still active:

❌ Order placed → Event → App Builder → apply store credit  (cart is inactive — fails)
✅ PlaceOrderPlugin → BalanceManagementInterface::apply() → place order → Event

App Builder receives the event after credit is already applied.

Real-world App Builder apps

Adobe and partners ship production patterns you can study:

• Amazon Sales Channel — marketplace integration on App Builder
• Admin UI SDK — embed custom React panels inside Commerce Admin
• Adobe Exchange apps — install pre-built App Builder apps (e.g. Feed Generator)
• I/O Events → Slack — operational notifications from Commerce events

Installing apps from Adobe Exchange

1. Browse Adobe Exchange for Commerce App Builder apps
2. Acquire and approve the app in your org
3. Configure deployment environments (stage / prod)
4. Validate the app is running via Developer Console

No custom code required for off-the-shelf extensions.

Getting started checklist

• Access Adobe Developer Console + App Builder entitlement
• Create a project and workspace (stage + prod)
• Install AIO CLI (@adobe/aio-cli)
• Scaffold: aio app init or clone app-builder-samples (opens in new tab)
• Configure Commerce Integration (OAuth) + REST permissions
• Enable Adobe I/O Events module in Commerce (2.4.4+)
• Deploy: aio app deploy → test runtime URL

Key developer resources

Summary

Adobe App Builder = serverless, out-of-process extensibility for Commerce.

• Actions for backend logic on I/O Runtime
• I/O Events for async Commerce triggers
• web-src for optional React UIs
• PHP stays where synchronous cart/checkout internals are required

Start small: one event, one action, one REST call — then grow into composable integrations.

Questions? Explore the tutorials on Experience League or clone the sample apps.