Commerce Apps Overview

A Commerce App is a packaged, installable solution that bundles frontend UI components, backend server-side code, admin configuration, and platform data into a single deployable unit called a Commerce App Package (CAP). Commerce Apps represent the evolution of the Commerce Cloud cartridge model into a marketplace-ready packaging format designed for plug-and-play installation.

This guide is for two audiences who share the same CAP format and install job:

• ISVs publish to the Commerce App Registry. Merchants discover those apps in Business Manager and click to install.
• SIs build merchant-specific private apps. They install from WebDAV (AppSource=WebDAV, feature type CUSTOM_APP) and don’t appear in the Cart & Checkout Hub catalog. See Develop a Private Commerce App.

For merchants, public Commerce Apps are discoverable in Business Manager. For ISV and SI developers, Commerce Apps can be managed through pro-code CLI solutions with automated local-to-cloud deployments and CI/CD integration. Both paths converge on the same platform framework.

The framework automates the orchestration of back-end extensions (cartridges, hooks) and frontend UI components for Storefront Next, significantly reducing implementation costs and time-to-value across the entire development lifecycle.

A Commerce App can include any combination of the following:

• Storefront Next extensions: React components, React hooks, routes, and data providers that render in UI target locations across the storefront (PDP, PLP, Cart, Checkout, My Account, and so on).

• Backend cartridges: Server-side scripts, controllers, and hooks that implement business logic. These include both site cartridges (storefront logic) and BM cartridges (admin functionality).

  • Domain-specific hook implementations: Script API implementations that fulfill platform-defined extension point contracts (for example, sfcc.app.tax.calculate).

  • Custom SCAPIs: Custom API endpoints for headless/API-driven backend functionality.

  • IMPEX data: Site-scoped XML for services, jobs, site preferences, custom object definitions, and metadata. Includes both install and uninstall payloads.

• App configuration: A tasksList.json file that defines the post-install configuration wizard steps a merchant must complete to activate the app.

• App manifest: A commerce-app.json file that defines the app’s identity, version, domain, and publisher information. See commerce-app.json Schema.

Depending on what you build, your app follows one of three architectures: UI-only (frontend extensions only), Backend-only (extension point hook implementations only), or Fullstack (both frontend and backend, with two sub-types: extension points or custom SCAPI). See The Three Architectures for Commerce Apps for details.

Commerce Cloud developers are familiar with cartridges as the primary unit of extensibility. Commerce Apps build on cartridges but add significant new capabilities:

• Automated installation: No more manual cartridge uploads, path editing, or IMPEX imports. The platform handles all of this through a single install job.

• Frontend orchestration: If your Commerce App includes Storefront Next components, installation can create a pull request that adds them to the merchant’s storefront repository. The UI Targets framework then renders these components in the appropriate locations.

• Domain isolation: Commerce Apps introduce domain-specific extension points (for example, sfcc.app.tax.calculate instead of the shared dw.order.calculateTax) that eliminate code conflicts between integrations.

• State tracking: The platform tracks installation status, configuration progress, and activation state per-site through the CommerceFeatureState system.

• Optional registry distribution: ISVs can publish apps to the centralized Commerce App Registry for discovery and installation. Private apps use WebDAV instead.

Use Claude Code’s /scaffold-app skill to scaffold a new Commerce App in seconds. The skill generates a complete app directory structure with templates for commerce-app.json, tasksList.json, and starter IMPEX files. Additional skills for IMPEX generation (/generate-service-impex, /generate-site-preferences-impex), validation (/validate-app), and packaging (/package-app) are also available. See Development Environment Setup for the full list.

Building a Commerce App follows this lifecycle:

1. Understand the architecture: domains, extension points, UI targets, and the three architectures.

2. Set up your development environment and sandbox.

3. Build your app: implement extension points, build UI extensions, create IMPEX data.

4. Package your app into a Commerce App Package (CAP) following the required structure.

5. Test and validate on a sandbox. ISVs also use the review checklist before registry submission.

6. Distribute:

   • ISVs: Publish to the App Registry for review and BM discoverability.
   • SIs: Install privately with b2c cap install (WebDAV). Do not open a registry PR.

7. Maintain the installed app (replication, multi-site, monitoring). Registry versioning applies to ISVs only.