Use the Managed Runtime API to control applications deployed to B2C Commerce’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.
Considerations
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.
To read and load redirects use the managed endpoint /mobify/redirects/$path.
Before You Begin
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.
Note
To make API requests, you must include an API key in the HTTP request Authorization header with the value, Bearer $API_KEY.
Treat your API key like a password because it allows scripts to perform operations on your behalf.
Note
Tutorial
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.
List Environments
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:
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:
Changing the configuration redeploys the deployed bundle so that the configuration update takes effect.
Troubleshooting
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.
Automation Users 🤖
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.
Rate Limits
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.
How to Read the Numbers
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.
Important
Projects and Environments
Method
Endpoint
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 Limit
Cumulative 1 Hour Limit
10
100
Cache Invalidations
Method
Endpoint
5 Minute Limit
1 Hour Limit
POST
/api/projects/*/target/*/invalidation/
15
100
Default Rate Limits
Method
Endpoint
1 Minute Limit
1 Hour Limit
GET
All endpoints combined.
1000
N/A
POST, PATCH, DELETE
All remaining endpoints combined.
100
N/A
Next Steps
Now you’re familiar with what the API can do—and even made some sample requests!