Managed Runtime API

Use the Managed Runtime API to control applications deployed to Commerce Cloud’s Managed Runtime. You can create custom tooling that has the same functionality as the Runtime Admin web application, but you get even more administration abilities and configuration options.

The Managed Runtime API is for administration purposes only. Do not make requests to the API in your storefront code. Requests that exceed rate limits are blocked.

This guide assumes that you're already familiar with Managed Runtime and related concepts, such as: projects, environments, bundles, and deployments. To learn more, see the Managed Runtime Overview.

The Mobify brand name still appears in the mobify.com domain in the base URL for the Managed Runtime API. Although new Salesforce domains will eventually take the place of the Mobify domain, support for the Mobify domain will continue.

To make API requests, you must include an API key in the HTTP request Authorization header with the value, Bearer $API_KEY.

To find your API key, log in to the Runtime Admin tool and go to the Account Settings page.

Treat your API key like a password because it allows scripts to perform operations on your behalf.

We’re about to show you how to use the API with a brief tutorial based on some sample requests, which are formatted as curl commands.

Before running the commands, replace any placeholders with actual values. Placeholders are formatted like this: $PLACEHOLDER.

For most requests, you must replace $PROJECT_ID with your actual project ID. To look up your project ID, log in to the Runtime Admin tool and go to your project’s settings page.

Project IDs can be up to 20 characters long and must be unique globally.

Our first request to the Managed Runtime API lists all the environments (or "targets" as they're called in the API) that belong to a project:

Call the projects_target_list API endpoint to list the environments:

Now let’s create an environment called staging that we can use to verify changes before deploying them to production:

First call the projects_target_create API endpoint. If you’re creating a project, you can call the projects_create API endpoint to also create an environment:

Then call the cc_b2c_target_info_update API endpoint to connect a Commerce Cloud instance and one or more sites to the environment.

To use your new environment, you must deploy a bundle to it.

Let’s call the projects_target_retrieve API endpoint to review the details of the staging environment that we created:

Finally, let’s call the projects_target_partial_update API endpoint to modify the proxy configuration for staging:

Changing the configuration redeploys the deployed bundle so that the configuration update takes effect.

If you’re having trouble using the API, try these troubleshooting steps.

  • Add the --fail argument to your curl command.
  • Check your API key.
  • Check your project’s ID.

The API endpoints also work in a browser. Log in to the Runtime Admin tool then open the endpoint you’re using directly in your browser.

To support continuous integration and deployment using the Managed Runtime API, create an Account Manager user for automation:

  • Create a user account in Account Manager using a shared email address like a Google Group. Store the associated credentials and MFA code in a password manager like LastPass.
  • Give the user the Managed Runtime User role.
  • Assign the user the required permissions in Runtime Admin. The user's Managed Runtime API key can only access what is allowed by the user's permissions. Keep them specific to the projects that CI/CD needs to interact with.
  • Create the API key for the user and save it in your continuous integration system.

To keep the Managed Runtime API key active, you must keep the related Account Manager account active by updating its password as required by your organization's Account Manager configuration. If the user is deactivated, reactivate it by resetting the password to re-enable the API key.

The Managed Runtime API has rate limits in place for the number of requests allowed per unit of time. Rate limits are applied on a per-user basis, and help ensure fair access for all users.

If your request exceeds a rate limit, the API returns an HTTP 429 Too Many Requests error, and a Retry-After HTTP header that indicates the number of seconds to wait until you can retry.

Rate limits cannot be adjusted.

The tables below indicate the rate limits for different API families.

Some endpoints have cumulative rate limits, which means they are not throttled on a per-endpoint basis. Instead, cumulative rate limits throttle the combined number of requests across multiple endpoints. All GET requests have a cumulative rate limit. Similarly, all POST, PATCH, and DELETE requests for endpoints that are not individually called out in the following tables have a cumulative rate limit. These limits are described below.

MethodEndpoint
POST/api/projects/
PATCH/api/projects/*/
DELETE/api/projects/*/
POST/api/projects/*/builds/*/
POST/api/projects/*/target/
PATCH/api/projects/*/target/*/
DELETE/api/projects/*/target/*/
POST/api/projects/*/target/*/deploy/
Cumulative 1 Minute LimitCumulative 1 Hour Limit
10100
MethodEndpoint5 Minute Limit1 Hour Limit
POST/api/projects/*/target/*/invalidation/15100
MethodEndpoint1 Minute Limit1 Hour Limit
GETAll endpoints combined.1000N/A
POST, PATCH, DELETEAll remaining endpoints combined.100N/A

Now you’re familiar with what the API can do—and even made some sample requests!

To learn more about the API, refer to the API Specification.

The Open API schemas for the API are available at: