First of all, if you're a tech guy, you might want to check out our Developer Portal to get access to extensive knowledge on how our Decision API works, but do feel free to read this article, which is shorter but still useful.

Why the Decision API?

The Decision API is a managed REST API. This means that it’s agnostic and can be plugged anywhere. It’s called Decision API because it’s a decisional API. Based on a JSON body, it will return some flags and their values, which you will want to display to your users. The whole logical condition is based on the API instead of your application/website.

What does it stand for?

It enables developers to get flag values depending on specific visitors' context and to carry out certain experiments and feature management.
A flag is a remote variable that you can play with to change its value and therefore the behavior of your app/website. Every flag implemented in your codebase and linked to Flagship can be played with.
E.g.: “app_paymentScreen_paypal”: true would enable the Paypal payment method in the payment screen of the app, and false would disable it, if your developers implemented the same logic.

How does it work?

The following behavior can differ depending on developer implementation, but let’s imagine the following workflow:
A user arrives on your website. Like for any normal website navigation, the browser calls your server and is waiting for an answer. At this moment, your server is calling the Decision API with the unique visitorId of your visitor and gets a fast answer with the flags he has to activate/play with. These flags were configured inside the Flagship dashboard beforehand.

What is the role of each body parameter?

visitorId = anonymized unique identifier given by your developers
context = context of your visitor, it can be technical (device, geolocation, browser, etc.) but also behavioral (early adopters, loyalty program, cart amount, etc.)
trigger_hit = this parameter aims at specifying to Flagship that a user has been assigned to a feature and has correctly seen it. This means that all flags returned by the Decision API would make a +1 count in the reporting of each feature if set to true. It can be set to false only if you want to get the different flag and tell the Decision API that the user saw it later. For example, you are targeting several features for “All users”, but one of the features is only present in the cart page. Then, you will set that parameter to false, and trigger what we call an “activate endpoint” to say “My visitor now sees the feature”.
decision_group = all visitors with the same decision_group will see the same flag value based on the first to trigger it. This can be useful when you want all people from the same company to see the exact same variation of an experiment.
X-api-key = this is an authentication option linked to your account environment, to make sure that you and only you are calling the Decision API. Each environment has their own API Key.

If you need more information, please don’t hesitate to contact our support team, we’ll be happy to help you!