SFCC dw.json Validator & Builder — B2C Commerce
Skip to main content

dw.json Validator & Builder

Build a clean dw.json or paste an existing one to catch hostname patterns, missing code-version, placeholder credentials, and bad cartridge entries.

e.g. zzzz-001.dx.commercecloud.salesforce.com

app_storefront_base, modules

Generated dw.json
Fill the form to generate dw.json…

About dw.json Validator & Builder

Build a valid dw.json from scratch or paste an existing one to catch common mistakes: hostname with a scheme prefix, placeholder credentials, missing code-version, bad cartridge names, and production realm warnings. Every SFCC developer touches this file daily — getting it right saves the first 10 minutes of every debugging session.

Environment detection

The validator recognises on-demand sandbox hostnames (zzzz-001.dx.commercecloud.salesforce.com), staging, development, and production realms, and warns when you are pointing at production.

Pipeline

Frequently asked

What is dw.json?
dw.json is the configuration file read by the Salesforce B2C Commerce CLI (sf commerce), the VS Code Cartridges extension, and sfcc-ci. It tells these tools which sandbox to connect to, which code version to deploy to, and how to authenticate. It lives at the root of your project and should be gitignored.
Should I commit dw.json to source control?
No. dw.json contains credentials (BM access key or OAuth client secret) and a hostname that is specific to your sandbox. Commit a dw.json.example with placeholder values instead, and add dw.json to .gitignore.
What is the difference between username/password and client-id/client-secret auth?
Username/password uses your Business Manager login and a BM access key (not your BM password). This is the simplest setup for individual developers. Client-id/client-secret uses an Account Manager OAuth client — required for CI/CD pipelines and shared environments where individual credentials are not appropriate.
What is the code-version field?
The code version is the slot in Business Manager where your cartridge code is deployed. You can have multiple code versions (e.g. version1, version2, feature-branch) and activate one at a time. The CLI deploys to the version named in code-version and does not automatically activate it.
What does the self-signed field do?
Setting self-signed: true tells the CLI to accept self-signed TLS certificates. This is sometimes needed for on-premise or custom-domain sandboxes. Never set it for production instances.