Back in October, we launched our very first REST API endpoint (GET /features) to list all of the feature flags in your GrowthBook account. Since then, we've been adding new endpoints and improving documentation. There's still a lot of work to do, but we wanted to highlight some of the cool new use cases unlocked by our recent work.

OpenAPI and New Documentation

Our REST APIs are now fully documented using the latest OpenAPI 3.1 standard. For those unfamiliar with OpenAPI (formerly Swagger), it's a standardized way to describe API endpoints, their inputs and outputs, and how everything ties together.

The coolest part about this is our new documentation site - Everything you see there is 100% auto-generated. When we add a new API endpoint or change the source code, the docs will always stay completely up-to-date. This lets us iterate quickly and is the main reason we've been able to add so many new endpoints in such a short amount of time.

Syncing Experiment Results to a Data Warehouse

When you run an experiment in GrowthBook, we query the raw data in your data warehouse, do some fancy aggregations, and pass it through our statistics engine. This final processed data is what powers the GrowthBook UI. But what if you want these processed results to be available back in your data warehouse alongside the raw data?

This is something we want to eventually support natively in GrowthBook, but now that we have a REST API, you no longer need to wait for us to implement this functionality. Now, you can use the /experiments/{id}/results endpoint and a cronjob to build out this functionality yourself.

Automatically Disable a Feature Based on Guardrails

If you launch a feature as an A/B test, we let you specify Guardrail Metrics in GrowthBook. These are things you are not specifically trying to improve but want to keep an eye on. For example, if you're testing a new signup form, you might add "bounce rate" as a guardrail.

To use this guardrail today, you have to manually log into GrowthBook, refresh experiment results, and if you notice a guardrail metric is failing, manually disable the feature flag.

Using the REST API, you can now fully automate this process. Fetch experiment results and use the /features/{id}/toggle endpoint to disable a feature programmatically if you detect a failing guardrail.

And lots more...

Check out the docs at for all of the currently supported endpoints.

Most of the endpoints are read-only today, but we're adding support for other methods shortly to unlock even more advanced use cases.