---
schema_version: "1"
id: f08ee9856f99ad1b77305f8cc5aa829df84cdc30532384e55a60ffea6c8bcd2b
title: Configuration Files
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/commerce-cloud/pwa-kit-managed-runtime/guides/configuration-options.md
canonical_url: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/configuration-options.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: c145408923142e0909f63d0ad92aafc4e84bfd11d63326fe21782255b844be50
products:
  - Composable Storefront
  - Salesforce APIs
---
# Configuration Files

With configuration files, you can customize many aspects of how your PWA Kit application works, including: API access, URL formatting, handling multiple sites, request proxying, and server-side rendering.

A configuration file can be written in your choice of JavaScript, YAML, or JSON. The following file extensions are supported: `.js`, `.yml`, `.yaml`, and `.json`.

When a PWA Kit project is created with the Retail React App template, it comes with a single configuration file: `/config/default.js`. The configuration objects that it exports are set based on the options provided to `pwa-kit-create-app`, but you can update your configuration at any time. Updates are often necessary after the initial project generation to stay in sync with changes to B2C Commerce instances.

**note:** To support isomorphic rendering, configuration values are serialized to page. **Don't place secrets in your configuration!**

You can replace `default.js` or complement it with additional configuration files because PWA Kit supports environment-specific configurations, which are covered later in this guide.

Let's start by looking at the specific configuration objects and properties available in `default.js` or any configuration file.

**note:** The project string that associates your application with Managed Runtime is _not_ part of a configuration file, but can be found in the `name` property at the top of the `package.json` file at the root of your project directory. After initial project generation, you can change the value of `name` to match the project ID that you see in Runtime Admin.

## API Access

**note:** Before version 1.5.0 of PWA Kit, these settings were in `api.config.js`.

To configure access to the B2C Commerce API and Open Commerce API (OCAPI), you can edit the `app.commerceAPI` object that is exported from the configuration file.

Here's an annotated code snippet with example values:

```javascript
commerceAPI = {
  proxyPath: `/mobify/proxy/api`,
  parameters: {
    clientId: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', // Client ID (UUID) for API access used by the Shopper Login and API Access Service (SLAS)
    organizationId: 'f_ecom_xxxx_xxx', // Organization ID from Business Manager
    shortCode: 'xxxxxxxx', // Short code from Business Manager
    siteId: 'RefArch' // Site ID from Business Manager
  }
}
```

To configure access to the Einstein API, you can edit the `app.einsteinAPI` object.

Here's another annotated code snippet with example values:

```javascript
einsteinAPI = {
  host: 'https://api.cquotient.com',
  einsteinId: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', // Client ID (UUID) for API access used for Einstein API
  // This differs from the siteId in commerceAPIConfig for testing purposes
  siteId: 'aaij-MobileFirst'
}
```

For more information on the `CommerceAPI` class that consumes the configuration object in the previous code snippet, see our architecture guide to [The Retail React App](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/retail-react-app.md#commerce-api).

For more information on the setup tasks in Account Manager and Business Manager to enable API access for a B2C Commerce instance, see our guide to [Set Up API Access](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/setting-up-api-access.md).

## URL Formatting

You can customize how storefront URLs are formatted in the `app.url` object.

The `app.url` object is configured with the following values by default:

```javascript
url: {
    site: 'path',
    locale: 'path',
    showDefaults: true
},
```

With these defaults settings, both the current site and locale are displayed in the URL path.

You can choose how the current locale appears (or doesn’t appear) in the URL by setting `url.locale` to one of the following values:

- `path`: Locale is included in the URL path. Example: `/en-US/women/dress`
- `query_param`: Locale is included as a query parameter. Example: `/women/dress?locale=en-US`
- `none`: Locale isn’t included in the URL. Example: `/women/dress`

`url.showDefaults`: This boolean value dictates whether the default site or locale values are shown in the url. Defaults to: false.

## Handling Multiple Sites

We extract the sites configured for your application into its own file called `config/sites.js`. This file is imported into each configuration file and exported within the `app` object. Separating the files this way allows you to more easily synchronize the sites supported by your application and the sites defined in your Business Manager backend. (You can define your sites directly in the configuration file, if you prefer.)

The `app` object also contains other settings for managing multiple sites and their aliases. These settings are covered in more detail in our guide to [Multiple Sites](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/multiple-sites.md).

## Request Proxying

Request proxying is configured in the `ssrParameters.proxyConfigs` array, which is covered in detail in our guide to [Proxying Requests](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/proxying-requests.md).

## Server-Side Rendering

**note:** Before version 1.5.0 of PWA Kit, these settings were in `package.json`.

The following table highlights the configuration options related to server-side rendering. These options are not part of the `app` object and are expressed as individual properties of the main `exports` object.

<table>
<thead>
<tr>
<th colspan="1" rowspan="1">Property</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="1" rowspan="1"><code>ssrParameters.ssrFunctionNodeVersion</code></td>
<td colspan="1" rowspan="1">String that determines which version of Node to use for running the App Server.<br />
<br />

Allowed values: Supported [Node version](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/upgrade-node-version.md#supported-node-versions)</td>

</tr>
<tr>
<td colspan="1" rowspan="1"><code>ssrEnabled</code></td>
<td colspan="1" rowspan="1">Boolean that enables or disables building the files necessary for server-side rendering. <b>Setting this value to <code>false</code> is deprecated as of August 2021</b>.</td>
</tr>
<tr>
<td colspan="1" rowspan="1"><code>ssrOnly</code></td>
<td colspan="1" rowspan="1">Array of <a href="https://www.npmjs.com/package/minimatch">glob expressions</a> where <code>*</code> is a wildcard matching zero or more instances of any character. <br /><br />Determines which files are available exclusively to the server-side rendering system and are <i>not</i> available through the <code>/mobify/bundle/</code> path.<br />
<br />
Defaults for a newly generated project: <code>['ssr.js', 'ssr.js.map', 'node_modules/**/*.*']</code>

</td>
</tr>
<tr>
<td colspan="1" rowspan="1"><code>ssrShared</code></td>
<td colspan="1" rowspan="1">Array of <a href="https://www.npmjs.com/package/minimatch">glob expressions</a> where <code>*</code> is a wildcard matching zero or more instances of any character.<br /><br />Determines which files <i>are</i> available to the server-side rendering system <i>and</i> available through the <code>/mobify/bundle/</code> path.<br />
<br />
Defaults for a newly generated project:

```javascript
"ssrShared": [
"static/ico/favicon.ico",
"static/robots.txt",
"**/*.js",
"**/*.js.map",
"**/*.json"
]
```

</td>
</tr>
</tbody>

</table>

## Environment-Specific Configurations

You can include multiple configuration files in the `config` directory, including configuration files for specific environments.

Environment-specific configurations can make your deployments more efficient and flexible. For example, you can:

- Deploy a single bundle to multiple Managed Runtime environments and have each of environment connect to a different B2C Commerce instance.
- Connect to your own on-demand sandbox during local development but connect to different instances when deployed to Managed Runtime.

To create an environment-specific configuration file, follow the same conventions used in `default.js`, but use the name of the target environment as the base name of the file. Use any of the supported file formats and the corresponding file extension. Examples: `production.js`, `staging.json`.

## Loading the Right Configuration

A PWA Kit application chooses the right configuration file to load by searching the `config` directory and asking the following questions, in the following order:

1. Is there a file that matches the name of the currently running environment on Managed Runtime?
2. If it's running locally, is there a file called `local` with a supported file extension?
3. If no configuration file has been found yet, is there a file called `default` with a supported file extension?

As soon as the answer to one these questions is "Yes," PWA Kit stops looking and loads the file in question.

If two files have the same base name but different file extensions, the file extension with the highest assigned precedence is chosen. The supported file extensions are assigned precedence in the following order, ranging from highest to lowest precedence: `.js`, `.yml`, `.yaml`, or `.json`. That means that between `default.js` and `default.json`, PWA Kit would load `default.js` because it has the higher precedence.
