B2C MRT Skill
Use the b2c CLI to manage Managed Runtime (MRT) projects, environments, bundles, and deployments for PWA Kit storefronts.
Tip: If
b2cis not installed globally, usenpx @salesforce/b2c-cliinstead (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>), the mrt env var family (list / set / push / delete), and the mrt env access-control family (list / create / get / 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 usesfcc.storefront.deployments[.rw]; env var and access-control commands usesfcc.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, env var, and access-control commands above).
Notes:
- Under
--json, these commands emit the serving backend's native shape (e.g.bundle historyis legacy{count, next, previous, deployments}vs SCAPI{limit, offset, total, data};env var listis legacy{count, variables}vs the SCAPI native environment-variables map). The human table is normalized;--jsonis not. Pinlegacyorscapiwhen a script needs a stable shape. - Env vars over SCAPI use the Storefront Environments API.
setanddeleteapply a merge-PATCH (only the keys you pass change;deletesends the key with anullvalue); values are always masked by both backends.pushresolves the backend once from its initial read and pins every write to it, so a singlepushnever crosses backends. - Access-control headers over SCAPI also use the Storefront Environments API.
getanddeletekey on the header UUID;createtakes the header value as a positional argument (201 Created returns the full masked header). Header values are always masked by both backends — the CLI never displays or reconstructs the plaintext value. - 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 everymrtcommand. Onmrt project createthis flag sets the new project's slug (auto-generated from the name if omitted);mrt bundle saveuses-dfor--save-dir, keeping-sfree 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 alice@example.com --org my-org --role member --view-all-projects
b2c mrt org member update alice@example.com --org my-org --no-cert-permission
b2c mrt org member remove alice@example.com --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 user@example.com -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.