OpenFeature

OpenFeature is an open standard and Cloud Native Computing Foundation (CNCF) project that provides a vendor-neutral API for feature flag evaluation. Your application code calls the OpenFeature SDK, and a provider connects that SDK to a feature flag management system.

Unleash providers connect the OpenFeature SDK to Unleash. Each provider wraps an Unleash SDK, so Unleash still manages your flags, evaluates them, and collects usage metrics. Your application code depends only on the OpenFeature API.

How it works

• Your application evaluates a flag through an OpenFeature client, for example getBooleanValue("my-feature", false, context).
• The Unleash provider translates the OpenFeature evaluation context into an Unleash context.
• The underlying Unleash SDK evaluates the flag, using the same caching, polling, and metrics behavior as when you use the SDK directly.
• The provider returns the result to OpenFeature as a typed value, together with evaluation details such as the variant name.

Backend providers, such as Node.js and Python, wrap backend SDKs that evaluate flags locally and accept a context with every evaluation. Frontend providers, such as Swift and Android, wrap frontend SDKs that fetch flags evaluated for one context at a time. With a frontend provider, you set the context on the OpenFeature API, and changing it triggers a refetch from Unleash.

When to use OpenFeature

OpenFeature is a good fit when:

• Your organization standardizes on one feature flag API. Platform teams can give every service the same evaluation interface across languages and frameworks, and keep the choice of flag management system behind the provider.
• You’re migrating from another feature flag system. If your code already uses OpenFeature, you can switch to Unleash by swapping the provider, without changing evaluation call sites. See Migrate from LaunchDarkly for a step-by-step migration that includes this approach.
• You want to use OpenFeature hooks and ecosystem tooling. Hooks run custom logic before and after every flag evaluation, for use cases such as logging, telemetry, and validation. You register hooks on the OpenFeature API or client, so they work with the Unleash providers. Browse the OpenFeature ecosystem for available hooks.

If you don’t need a vendor-neutral API, use the Unleash SDK for your language. The Unleash SDKs support capabilities that the OpenFeature API doesn’t model, as described in OpenFeature providers compared with Unleash SDKs.

Available providers

Unleash maintains providers for the following languages:

The OpenFeature community maintains additional Unleash providers in the OpenFeature contribution repositories:

Unleash doesn’t maintain the community providers. Their release status, supported features, and context mapping can differ from the Unleash-maintained providers, so check each provider’s documentation before you adopt it. The JavaScript browser provider also works with the OpenFeature React and Angular SDKs.

Get started

Install the provider for your language, register it with OpenFeature, and evaluate a flag. Backend providers need a backend token, and frontend providers need a frontend token.

Unleash-maintained providers

npm install @unleash/openfeature-node-provider @openfeature/server-sdk unleash-client

import { OpenFeature } from '@openfeature/server-sdk';
import { UnleashProvider } from '@unleash/openfeature-node-provider';
const provider = new UnleashProvider({
  appName: 'my-node-app',
  url: '<YOUR_UNLEASH_URL>/api',
  customHeaders: {
    Authorization: '<YOUR_API_TOKEN>'
  }
});
await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();
const enabled = await client.getBooleanValue('my-feature', false, {
  targetingKey: 'user-123'
});

Community-maintained providers

go get github.com/open-feature/go-sdk-contrib/providers/unleash

How Unleash concepts map to OpenFeature

Flag evaluation

OpenFeature defines typed evaluation methods. The Unleash providers resolve them as follows:

Boolean evaluations return the flag’s enabled state, so a disabled flag returns false. For non-Boolean evaluations, a disabled flag or a missing or mismatched variant payload returns the default value you pass to the evaluation method. When a variant is assigned, detail methods such as getStringDetails report its name. Unleash SDKs don’t report why a flag evaluated the way it did, so most providers return the UNKNOWN evaluation reason.

Context mapping

The Unleash providers follow the same rules to map the OpenFeature evaluation context to the Unleash context:

• The targeting key maps to userId and takes precedence over a userId attribute.
• Attributes named after top-level Unleash context fields, such as sessionId and remoteAddress, map to those fields.
• All other scalar attributes become Unleash context properties, which you can use in strategy constraints. The providers discard nested values, such as lists and objects.

Each provider page lists the exact fields it maps.

OpenFeature providers compared with Unleash SDKs

OpenFeature models the capabilities that feature flag systems have in common. Unleash-specific capabilities that fall outside that common API aren’t available through the providers. The following table compares the Unleash providers with the Unleash SDKs they wrap.

In exchange, OpenFeature adds capabilities that sit above any single provider, such as hooks, named clients, and a consistent evaluation API across vendors. The Unleash providers don’t implement the OpenFeature tracking API.

To use all Unleash capabilities, including impression data, impact metrics, and safeguards, use the Unleash SDK for your language directly.