Today, we are happy to announce that the Split API now spans the full surface area of Split product functionality, including full management of feature flags (i.e. “Splits”). Via the Split API, you can now write code to programmatically create, modify, kill, or delete a Split. Or, go even deeper, by automatically changing a roll-out plan, including feature variations (i.e. “Treatments”) or traffic distribution.
Configure Split feature flags directly from Slack or your own internal admin console, or automatically from your monitoring tools with the new Split API. Other capabilities of the Split API include configuration of environments, traffic types, segments or customer identities. The Split API documentation has all the details.
But, we’re not here to sell you on the importance of an API as most of you already know that. Instead, we’ll walk you through a few compelling use cases we can enable.
The ability to control and change a feature behavior dynamically –aka feature flag— has deep implications for how we think about product development going forward. Moreover, when paired with an API that can be easily integrated with tools people already use, that’s where things start to become even more interesting.
The possible integrations that such an API can open up is quite diverse. Let’s explore few of them.
Deeper Slack / HipChat integration with feature flags
First, we see customers wanting an API for deeper integration with chat apps. We recently announced our out-of-the-box Slack integration and described how integrating with corporate chat products can create feature release awareness across the organization. Now having the ability to change a feature (kill, restore or update) via an API will allow developers to create more interactive bots capable of answering questions about a feature flag and even requesting a feature to be killed by just typing the command, all from within the chat application.
APM tool integration to automatically kill a feature
Another customer use case is automatic rollback or decrease of exposure of a feature when certain metrics exceed an allowed threshold. In this case, the APM product of your choice – we use Datadog – will not just trigger an alert on a metric, but will follow-through with an action to disable feature flags for an account or entirely kill a feature. For example, if your APM tool was set up for an acceptable threshold for an event called SAML_LOGIN_EXCEPTIONS, and that threshold was crossed for a given account id, it could automatically make a call to the Split API to disable SAML 2.0 for the problematic accounts, while also alerting the Ops team to the problem.
A more elaborate integration would contemplate ramping down a feature when a given metric reaches a warning threshold. In the example below (Figure 2) a warning threshold was set at 0.04 (exceptions per minute). The APM tool we use lets us trigger a webhook whenever a condition on a metric is reached. So, we set a webhook to get triggered to ramp down a feature from 100% to 25% of the user base. If a subsequent threshold is passed at the mark 0.07, then the webhook will completely disable the feature by calling the Kill Split endpoint for the Split API. This would prevent all users from authenticating via SAML.
Automating definitions for feature flags in your build process
At Split, we believe that all features that reach a production environment should be released behind a Split. It’s safer, since you can control when and to whom to release it to. It adds traceability – you know who was exposed to a feature and when. And, it enables other teams to control the release experience of their own features.
With the Split API, you can now add the creation of a Split as a step in your build process.
How? A step of the build can quickly scan part of the code and look for patterns of code that belong to a feature behind a Split. Then, the build can check if that Split exists in the target environment where it is going to be deployed, and if it doesn’t, it can create the Split.
We built a small example application as a reference that shows how to interact with our API.
Automate feature release your use your own management UX
Finally, customers have been asking us for a way they can further automate roll-out of features, or integrate feature flags into an admin console. The new API can handle both of these use cases. Build a custom script to gradually rollout your feature flag from 0% to 100% across time. Or, add a widget to your own internal admin console providing some simplified functionality, such as displaying the current rollout plan for a subset of your feature flag ecosystem, using the get and list API calls.
Try it yourself and share your feature flags use cases with us!
We think the use cases above are going to be really powerful ways to integrate feature flags deeply into how you build software, ultimately giving you the power to deliver a better user experience and hit the business goals for your product. But, we’re just getting started. We can’t wait to see all the ways our customers power their product decisions with Split and innovate with the Split API!
Give it a try, and let us know how you use it! If you’re not already using Split, get started today with a free trial. Our free trial lets you try out every feature in Split for free for 14 days.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Become more data-driven around feature releases by using impression data from Split in mParticle and mParticle event data to evaluate treatments in Split.
Google Analytics is the most popular web performance tool out there. Nearly every web app uses it. And given the metrics that GA collects — sessions, pageviews, conversion rates, page load timing — it’s a logical dataset to pair with feature flags. So we’re excited to announce our latest, very…
New Relic and Split enable customers to make data-driven decisions using feature flags, with a shared belief that you can’t improve what you can’t measure.