APIs are a great way to execute repeatable actions via code instead of the UI. They provide the benefit of reusing your code vs. repeating the same action over and over again in the UI. Product development teams use our Optimizely Full Stack product to reduce risk when rolling out features and run product experiments to improve product metrics. We have recently enhanced Full Stack APIs with support for running experiments and rollouts in multiple environments, and updating feature variables. We’ll also show you how to read datafiles which are used to represent your experiments and feature flags conditions and provide the instructions to run experiments and roll out features. We will go through these use cases in this blog post using the example of an e-commerce business and show how you can use postman to explore the APIs
Using Postman
Internally, we use an API client postman to interact with the APIs which makes it easy to work with different development environments. It’s a great way to explore our APIs as you can make ad-hoc calls. To share the fun, we expose the APIs via a postman collection. You can learn more about how to import the collection and make calls to our APIs here.
Getting the most out of Full Stack APIs
Below are some key use cases for using our new Full Stack APIs to automate your experimentation and roll out strategy.
Fearless testing with environments
When building new features or experiments, you want to test them in non-production environments like dev or staging before you test in production. For instance, you have a crucial feature launching on Black Friday that you need to roll out to your customers and you’d like to test it with internal users first before going live. You can create a dev/staging environment using the environments API and enable the feature in that environment. After testing it, you can enable the feature in the primary (production) environment. Testing in non-production environments first helps you validate the feature without impacting valuable customers.
Starting/pausing experiments in different environments
You can set the status (start/pause) of an experiment in different environments using the experiments API using both create and update APIs. There’s a new property `environments` that can be used in the request payload to indicate the status per environment.
POST https://api.optimizely.com/v2/experiments | |
PATCH https://api.optimizely.com/v2/experiments/<experiment_id> | |
Sample request payload: | |
{ | |
"environments":{ | |
"staging":{ | |
"status":"running" | |
}, | |
"production":{ | |
"status":"paused" | |
} | |
} | |
} |
Create an experiment and start it in the staging environment. After testing it on staging, let’s pause the experiment in staging and start it in the production environment.
Rolling out features in different environments
Similar to experiments you can control a feature’s rollout in different environments using features API and including `environments` properties in the request payload
POST https://api.optimizely.com/v2/features | |
PATCH https://api.optimizely.com/v2/features/<feature_id> | |
Sample request payload: | |
{ | |
"environments":{ | |
"staging":{ | |
"rollout_rules":[ | |
{ | |
"enabled":true | |
} | |
] | |
} | |
} | |
} | |
Enable a feature in the staging environment
Implementing a scheduler
There will be scenarios when you want to start/pause an experiment at regular intervals without manual intervention such as starting experiment at beginning of every weekend and pause it on weekdays. To do that, you can create/use a cron job in your application and have it execute the experiments API to start/pause the experiment. There are two ways to use the API depending on your case.
If you want to interact with only the primary environment then you can use the`action` query parameter and send a PATCH request to the experiments API.
PATCH – https://api.optimizely.com/v2/experiments/<experiment_id>?action=start
Starting an experiment in the primary environment
If you want to interact with a non-primary environment then you can use the `environments` request property as described above and send a PATCH request to the experiments API. Similarly, you can implement a scheduler using a cron job for enabling/disabling features by using the `environments` property.
Remotely configuring your application with feature variables
Feature variables enable you to updating your application configuration in real-time which helps you be more nimble and iterative. Coming back to the example of an e-commerce merchant, you might want to give a limited time discount for new users. You can create a feature to toggle on or off the promotion and use a feature variable to configure the promotion value. You can do this with the API call below:
PATCH https://api.optimizely.com/v2/features/<feature_id> | |
Sample request payload: | |
{ | |
"variables":[ | |
{ | |
"default_value":"30", | |
"id":13322300314 | |
} | |
] | |
} |
Updating the feature variable to change the promotion from 10 to 30 percentage off
Retrieving the datafile
If you want to fetch datafile of an environment securely via API instead of using the CDN url shared in the UI then you can use the environments API.
GET https://api.optimizely.com/v2/environments/<environment_id>/datafile
We are super excited to see you all build awesome things using the APIs and postman collection. We’d love to hear your feedback and experiences. Please use the feedback button on the top right corner of the developer docs.