Getting Started with OpenFeature
Traditionally, every feature flag vendor has had its own SDK with its own API. Switching vendors forced rewriting every flag evaluation in your codebase. OpenFeature fixes this by defining a standard interface that works with any backend.
Flipswitch is built entirely on OpenFeature. It’s not a proprietary platform with an OpenFeature adapter bolted on. The OpenFeature SDK is how you use Flipswitch. There’s no separate Flipswitch API to learn.
This guide explains what OpenFeature is, why it matters, and how Flipswitch uses it as its native interface.
What is OpenFeature?
OpenFeature is an open standard for feature flag evaluation. It’s a CNCF (Cloud Native Computing Foundation) project that defines:
- A standard SDK API: the same method signatures across languages
- A provider interface: vendors implement this to plug into the SDK
- Evaluation context: a standard way to pass user/request attributes
- Hooks: lifecycle callbacks for logging, metrics, and validation
Think of it like JDBC for databases or OpenTelemetry for observability. You write your code against the standard API, and the vendor-specific details are handled by a pluggable provider.
Why vendor-neutral matters
Without OpenFeature, switching from Vendor A to Vendor B means:
- Replacing every SDK import
- Rewriting every flag evaluation call
- Adapting to a different context/targeting model
- Updating every test that mocks flag evaluation
With OpenFeature, switching vendors means changing one line, the provider initialization. Every flag evaluation in your codebase stays exactly the same.
// Before: vendor-specific
import { VendorAClient } from 'vendor-a-sdk';
const client = new VendorAClient('api-key');
const value = client.isEnabled('my-flag', user);
// After: OpenFeature (works with ANY provider)
import { OpenFeature } from '@openfeature/server-sdk';
const client = OpenFeature.getClient();
const value = await client.getBooleanValue('my-flag', false);
Even if you never switch vendors, OpenFeature gives you:
- Consistent API across all languages your team uses
- Hooks for logging, metrics, and validation: written once, working across all flags
- Testability: mock the provider interface instead of vendor-specific details
Core concepts
The SDK
OpenFeature SDKs are available for all major languages:
- JavaScript/TypeScript (server + web)
- Python
- Go
- Java
- .NET
- PHP
- Ruby
- Rust
- Swift
- Kotlin
Each SDK exposes the same core API:
const client = OpenFeature.getClient();
// Boolean flags
await client.getBooleanValue('dark-mode', false);
// String flags
await client.getStringValue('checkout-variant', 'control');
// Number flags
await client.getNumberValue('rate-limit', 100);
// Object/JSON flags
await client.getObjectValue('banner-config', { show: false });
The Provider
A provider is the bridge between the OpenFeature SDK and a feature flag backend. Each vendor implements a provider that plugs into the standard SDK.
Flipswitch’s entire SDK ecosystem is built as OpenFeature providers. There is no proprietary client library. The Flipswitch provider is the only thing you install alongside the OpenFeature SDK:
import { FlipswitchServerProvider } from '@flipswitch-io/server-provider';
import { OpenFeature } from '@openfeature/server-sdk';
const provider = new FlipswitchServerProvider({ apiKey: 'your-api-key' });
await OpenFeature.setProviderAndWait(provider);
From this point on, every client.getBooleanValue() call is resolved by Flipswitch. If you ever switch providers, you change this initialization, nothing else.
Evaluation Context
The evaluation context carries information about the current user or request. Providers use this for targeting and segmentation.
// Set global context (applies to all evaluations)
await OpenFeature.setContext({
targetingKey: 'user-123',
});
// Or pass per-evaluation context
await client.getBooleanValue('premium-feature', false, {
targetingKey: 'user-123',
email: 'user@example.com',
plan: 'pro',
region: 'eu',
});
Hooks
Hooks let you run code at different stages of flag evaluation: before, after, error, and finally. They work across all flag evaluations regardless of provider.
const loggingHook = {
after: (hookContext, evaluationDetails) => {
console.log(
`Flag ${hookContext.flagKey} evaluated to ${evaluationDetails.value}`
);
},
};
OpenFeature.addHooks(loggingHook);
Common hook use cases:
- Logging every flag evaluation for debugging
- Recording metrics (evaluation count, latency)
- Validating that required context fields are present
Using Flipswitch with OpenFeature
Since Flipswitch is natively built on OpenFeature, getting started means installing the standard OpenFeature SDK and the Flipswitch provider for your language. There’s no separate API or proprietary client to learn.
Server-side (Node.js)
Install the OpenFeature SDK and the Flipswitch provider:
npm install @openfeature/server-sdk @flipswitch-io/server-provider
Initialize at application startup:
import { OpenFeature } from '@openfeature/server-sdk';
import { FlipswitchServerProvider } from '@flipswitch-io/server-provider';
const provider = new FlipswitchServerProvider({
apiKey: process.env.FLIPSWITCH_API_KEY,
});
await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();
Evaluate flags in your request handlers:
app.get('/dashboard', async (req, res) => {
const showBeta = await client.getBooleanValue(
'beta-dashboard',
false,
{ targetingKey: req.user.id, plan: req.user.plan }
);
res.render('dashboard', { showBeta });
});
Client-side (Browser)
For browser applications, use the web SDK:
npm install @openfeature/web-sdk @flipswitch-io/web-provider
import { OpenFeature } from '@openfeature/web-sdk';
import { FlipswitchWebProvider } from '@flipswitch-io/web-provider';
await OpenFeature.setContext({ targetingKey: getUserId() });
const provider = new FlipswitchWebProvider({
apiKey: 'your-client-api-key', // client-side key, safe to expose
});
await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();
const showNewNav = client.getBooleanValue('new-navigation', false);
Python
pip install openfeature-sdk flipswitch-provider
from openfeature import api
from flipswitch import FlipswitchProvider
provider = FlipswitchProvider(api_key="your-api-key")
api.set_provider(provider)
client = api.get_client()
show_beta = client.get_boolean_value("beta-dashboard", False)
Go
go get github.com/open-feature/go-sdk
go get github.com/flipswitch-io/go-provider
import (
"github.com/open-feature/go-sdk/openfeature"
flipswitch "github.com/flipswitch-io/go-provider"
)
provider := flipswitch.NewProvider("your-api-key")
openfeature.SetProvider(provider)
client := openfeature.NewClient("my-app")
showBeta, _ := client.BooleanValue(
ctx, "beta-dashboard", false, openfeature.EvaluationContext{},
)
OFREP: The wire protocol
OpenFeature also defines OFREP (OpenFeature Remote Evaluation Protocol), a standard HTTP API for flag evaluation. This means any OpenFeature-conformant provider can talk to any OFREP-conformant backend over a standard REST API.
Flipswitch natively implements OFREP, so you can use any OFREP-compatible client, not just Flipswitch’s own providers, to evaluate flags against the Flipswitch backend. This is another layer of vendor neutrality: even the wire protocol is an open standard.
In fact, all Flipswitch OpenFeature providers are built on top of the existing open-source OFREP providers maintained by the OpenFeature community. There’s no proprietary fork or custom protocol underneath. You get community-supported, battle-tested provider code with Flipswitch configuration and real-time updates on top. If a bug gets fixed upstream, you benefit. If the community adds a feature, you get it too.
Wrapping up
OpenFeature is the sane way to do feature flags. Write your evaluation code once against a standard API, and you’re never locked into a vendor again.
Flipswitch was built on this principle from day one. There’s no proprietary SDK to learn, the OpenFeature SDK is the Flipswitch SDK. Set up the provider, and you’re done.
Create a free Flipswitch account and follow our quick start guide to ship your first flag in about 5 minutes.