Skip to main content


Deprecated Features

The following table lists deprecated features and their respective shutdown dates.

FeatureDeprecated DateShutdown DateDetails
request_reactor_id and response_reactor_id removed from ProxiesNovember 30, 2022March 31, 2023In order to simplify management of Proxies, use of request_transform and response_tramsform has been recommended over Reactors.
Token Privacy SettingsOctober 13, 2022February 1, 2023Privacy settings (i.e. classification, impact level, and restriction policy) have been deprecated and replaced by a more flexible authorization model based upon Containers and Access Rules. For more information, see the section below on Migrating from Privacy Settings.
Reactor FormulasOctober 16, 2022February 14, 2024Reactor Formulas have been deprecated in favor of Reactors with code. For more information, see the section below on Migrating from Reactor Formulas.
Application Key RegenerateApril 17, 2024October 17, 2024Regenerating API Keys for an Application has been replaced with Application Keys, to Migrate you will Create a new Application Key and remove the old key.

Migrating From Privacy Settings

Privacy settings were previously used to scope access to Tokens based on their data classification and impact levels. In order to provide a more flexible access control model that can be customized per Application, we have introduced Token Containers to logically group Tokens according to any data governance requirements. A Token may be explicitly added to a container when creating the Token, or if unspecified, a Token will be placed within the container /<classification>/<impact_level>/ by default. If you were previously customizing a Token's classification or impact level, please update your systems to directly set the containers attribute instead.

Restriction policies were previously used in conjunction with impact level based read permissions (e.g. token:general:read:low) to define how Token data should be transformed when reading Tokens with a higher impact level than your permission allows. This model proved to be too inflexible as it was a global setting applied at the Token level and could not be customized per actor. Restriction policies no longer have any functional impact, and were replaced by transforms applied via Access Rules.

If your systems are using the privacy attribute of the Token Object in API responses, please update your integration to ignore this attribute as it will be removed on February 1, 2023.

Migrating From Reactor Formulas

Reactor Formulas were how you added code to a Reactor and configured some of its behavior. To offer less friction when creating Reactors, we have introduced a new code attribute to the Reactor Object. This attribute is a string containing the code that will be executed when the Reactor is triggered.

Alongside not having to create a new formula for each Reactor with different code, this new approach also removes some previous restrictions on configuration and request_parameters. Reactors with code will not provide validation of the configuration attribute or its request parameters, so you will need to perform this validation directly in your code if necessary.

If your systems are using the formula attribute of the Reactor Object in API responses, please update to use code instead. This can be done simply by taking the value for the code attribute on the formula and setting it as the value for the code attribute on the Reactor.

Below there are some examples on how this operation can be performed by retrieving the formula object and performing a [patch operation] in the Reactor:

curl "" \

You can continue to use your existing Reactors with formula until they are removed on a future date, but we advise you to migrate to code as soon as possible. Keep in mind that after migrating to code the formula will be removed from the Reactor but can still be retrieved for consulting purposes until the shutdown date.