Service Accounts & API Keys

Service Accounts

Service accounts are used for programmatic access to the features for an application through FeatureHub SDKs. A service account will need a minimum of READ access to an environment in order to access a feature value. You can set permissions for a service account from the FeatureHub Admin Console.

Service accounts

API Keys

When a service account is given access for an environment for a selected application, it automatically creates two types of API keys that you can choose from Client Evaluated API Key and Server Evaluated API Key. Read more info on API Keys types here

The same service account can be used across multiple environments and applications. We recommend two service accounts be created for an application, one with access to a production environment and the other one for test environments. However, FeatureHub remains flexible to how customers could split their service accounts according to individual needs.

API Keys

In case an API key gets compromised there is an option to reset the key and immediately disable the previous one.

Because API Keys are based on a service account ID, it is not possible to reset a single API key at a time, but there is an option to reset service account ID, which in turn will cause reset to all API keys attached to that service account. This could potentially affect multiple applications and multiple environments. Thus, it is recommended to always have a separate Service Account for a production environment. There is also an option to either reset Client evaluated API keys or Server evaluated API keys. Warning is provided before the reset. The option to reset the keys will only be available to Portfolio Admins and Super Admins, since service accounts settings can only be viewed by them. Only Portfolio and Super admins always have full permissions to see in which apps and environments a service account is used.

Service Account Permissions

For each application environment, there are permissions you can assign to service accounts.

  • READ Read the value of a feature

  • LOCK Can lock a feature, so its value can’t be changed, this gives us a safety net when deploying incomplete code into production. (Typically developers and testers keep features locked until they are finished and ready to be set)

  • UNLOCK Can unlock a feature, so it’s value can be changed

  • CHANGE_VALUE Can change the value of a feature or can "retire" a feature

CHANGE_VALUE permission supersedes the LOCK/UNLOCK.

Service Account Permissions