Feature Experimentation API

The Basics & Best Practices

On this page

Security and compliance

Our API is designed to meet all requirements for security, latency, robustness and flexibility.
In general, the API endpoints can only be accessed via HTTPS. The payload (bodies) of all requests and responses are JSON encoded.

Access to the API is only possible with a valid API token, which is checked for each access.
Our data center is located in Frankfurt, Germany.
We can also use a US data center upon request.

API endpoints

Endpoint urls


Asynchronous calls

It is possible to execute /decide API calls asynchronously as well.
The /track API calls are always asynchronous.
This can be used e.g. for experiments and features that are displayed after the current page/view has already been displayed to the user.

API limits

API endpoints are globally limited to 20,000 requests per minute.
This applies to one API token.
If you need more, please contact our support.

Batching requests

If multiple calls would be made to an endpoint at the same time, it is best practice to combine all calls per endpoint into one.

  • On the /decide endpoint, it is possible to pass multiple experiment IDs as an array as selector.experiments for this purpose
  • On the /track endpoint, it is possible to pass multiple events as an array as events for this purpose

Setting timeouts and handle errors

Our infrastructure is designed for low latency without very high availability.
Nevertheless, requests may take longer than usual or there may be temporary unavailability.
Also, requests may not be correct in the schema or payload, resulting in errors.

In general, especially the consumer of the /decide endpoint should be able to gracefully handle these occurrences.
A suitable early timeout is necessary. A fallback behavior in case of errors is also recommended.