b2c-mrt

B2C MRT Skill

Use the b2c CLI to manage Managed Runtime (MRT) projects, environments, bundles, and deployments for PWA Kit storefronts.

Tip: If b2c is not installed globally, use npx @salesforce/b2c-cli instead (e.g., npx @salesforce/b2c-cli mrt bundle deploy).

Configuration & Authentication

The CLI resolves the MRT API key from MRT_API_KEY (or SFCC_MRT_API_KEY), dw.json, ~/.mobify, or configuration plugins. Project and environment defaults can also come from package.json under b2c (mrtProject, mrtEnvironment) or environment variables. package.json cannot supply API keys or other secrets. Flags like --api-key, -p, and -e are usually unnecessary when defaults are configured — only pass them to override.

Run b2c setup inspect to see the resolved configuration and which source provided each value (use --json for scripting; keep secrets masked unless the user explicitly requests their values). For precedence rules and troubleshooting, see the b2c-cli:b2c-config skill.

MRT Backends (legacy vs SCAPI)

Most MRT commands run against the legacy MRT Cloud API (API key). Several commands can also run over the SCAPI MRT backend: mrt bundle history, mrt bundle list, mrt bundle deploy (both the local-build push and deploying an existing <bundleId>), and the mrt env var family (list / set / push / delete). Choose with --mrt-backend (MRT_BACKEND / SFCC_MRT_BACKEND, or mrtBackend in dw.json):

• auto (default) — use SCAPI when it's configured (--short-code + --tenant-id + client-credentials or JWT Bearer auth), otherwise legacy. Falls back to legacy on safe pre-execution errors. Each command requests its own scopes: bundle commands use sfcc.storefront.deployments[.rw]; env var commands use sfcc.storefront.environments[.rw] (reads accept either tier, writes require .rw).
• legacy — always the MRT Cloud API.
• scapi — always SCAPI, with no fallback; errors if prerequisites are missing. Also errors on unsupported commands (every MRT command except the bundle and env var commands above).

Notes:

• Under --json, these commands emit the serving backend's native shape (e.g. bundle history is legacy {count, next, previous, deployments} vs SCAPI {limit, offset, total, data}; env var list is legacy {count, variables} vs the SCAPI native environment-variables map). The human table is normalized; --json is not. Pin legacy or scapi when a script needs a stable shape.
• Env vars over SCAPI use the Storefront Environments API. set and delete apply a merge-PATCH (only the keys you pass change; delete sends the key with a null value); values are always masked by both backends. push resolves the backend once from its initial read and pins every write to it, so a single push never crosses backends.
• Legacy-only flags (--api-key, --cloud-origin / -u, --credentials-file / -c) are ignored — with a warning — when SCAPI serves the request.
• --storefront (long) and -s (short) are aliases of --project / -p — the SCAPI storefront ID is the project slug, so all four are interchangeable on every mrt command. On mrt project create this flag sets the new project's slug (auto-generated from the name if omitted); mrt bundle save uses -d for --save-dir, keeping -s free for the storefront alias.

Command Structure

mrt
├── org                          - Organizations and B2C connections
│   ├── member                   - Organization-level member management
│   └── cert                     - Custom domain certificates
├── project                      - Project management
│   ├── member                   - Team member management
│   └── notification             - Deployment notifications
├── env                          - Environment management (incl. clone)
│   ├── var                      - Environment variables
│   ├── redirect                 - URL redirects
│   └── access-control           - Access control headers
├── bundle                       - Bundle and deployment management (incl. delete)
└── user                         - User profile and settings

Quick Examples

Deploy a Bundle

# Push local build to staging
b2c mrt bundle deploy -p my-storefront -e staging

# Push to production with release message
b2c mrt bundle deploy -p my-storefront -e production -m "Release v1.0.0"

# Deploy existing bundle by ID
b2c mrt bundle deploy 12345 -p my-storefront -e production

# Build and upload a v2-format bundle (upload only; deploy the returned ID separately)
b2c mrt bundle upload-v2 -p my-storefront

Manage Environments

# List environments
b2c mrt env list -p my-storefront

# Create a new environment
b2c mrt env create qa -p my-storefront --name "QA Environment"

# Clone an existing environment (-e is the source; positional arg is the new slug)
b2c mrt env clone qa -p my-storefront -e staging --clone-redirects --clone-env-vars

# Get environment details
b2c mrt env get -p my-storefront -e production

# Invalidate CDN cache
b2c mrt env invalidate -p my-storefront -e production

Environment Variables

# List variables
b2c mrt env var list -p my-storefront -e production

# Set variables
b2c mrt env var set API_KEY=secret DEBUG=true -p my-storefront -e staging

# Delete a variable
b2c mrt env var delete OLD_VAR -p my-storefront -e production

View Deployment History

# List bundles in project
b2c mrt bundle list -p my-storefront

# View deployment history for environment
b2c mrt bundle history -p my-storefront -e production

# Download a bundle artifact
b2c mrt bundle download 12345 -p my-storefront

# Delete one or more bundles (uses bulk-delete for >1)
b2c mrt bundle delete 12345 -p my-storefront
b2c mrt bundle delete 12345 12346 12347 -p my-storefront --force

Organization Members and Certificates

Organization members are distinct from project members; they hold a role at the organization level. Custom-domain certificates are organization-scoped and referenced by b2c mrt env create/update/clone via --certificate-id.

# List, add, update, remove organization members
b2c mrt org member list --org my-org
b2c mrt org member add [email protected] --org my-org --role member --view-all-projects
b2c mrt org member update [email protected] --org my-org --no-cert-permission
b2c mrt org member remove [email protected] --org my-org

# Manage custom domain certificates
b2c mrt org cert list --org my-org
b2c mrt org cert create shop.example.com --org my-org   # output includes the DNS validation record
b2c mrt org cert get 123 --org my-org
b2c mrt org cert restart-validation 123 --org my-org
b2c mrt org cert delete 123 --org my-org

Project Management

# List projects
b2c mrt project list

# Get project details
b2c mrt project get -p my-storefront

# List project members
b2c mrt project member list -p my-storefront

# Add a member
b2c mrt project member add [email protected] -p my-storefront --role developer

URL Redirects

# List redirects
b2c mrt env redirect list -p my-storefront -e production

# Create a redirect
b2c mrt env redirect create -p my-storefront -e production \
  --from "/old-path" --to "/new-path"

# Clone redirects between environments
b2c mrt env redirect clone -p my-storefront --source staging --target production

Configuration

dw.json

Configure MRT settings in your project's dw.json:

{
  "mrtProject": "my-storefront",
  "mrtEnvironment": "staging"
}

Environment Variables

export MRT_API_KEY=your-api-key
export MRT_PROJECT=my-storefront
export MRT_ENVIRONMENT=staging
export MRT_BACKEND=auto        # auto (default) | legacy | scapi

~/.mobify Config

Store your API key in ~/.mobify:

{
  "api_key": "your-mrt-api-key"
}

Detailed References

• Project Commands - Projects, members, and notifications
• Environment Commands - Environments, variables, redirects
• Bundle Commands - Deployments, history, downloads

More Commands

See b2c mrt --help for a full list of available commands and options.