Start here
OpenFeature Compatibility
A practical view of where Zenmanage lines up with OpenFeature-style architectures today and where you should plan your own provider abstraction.
Current compatibility posture
Zenmanage already maps cleanly to several OpenFeature concepts: environments, evaluation context, typed flag values, provider-side rollout rules, and safe defaults in application code. What is not documented here is an official Zenmanage OpenFeature provider package. If your team uses OpenFeature today, plan on wrapping the SDK that best matches your runtime.
- Provider strategy: Use a thin adapter around the Zenmanage SDK so your application keeps an OpenFeature-shaped interface while Zenmanage continues to own remote evaluation and rollout logic.
- Evaluation context: Map OpenFeature evaluation context fields into Zenmanage context type, identifier, name, and attributes.
- Typed values: The currently documented flag types are boolean, string, and number. Keep provider contracts aligned to those types unless your own abstraction adds conversion behavior.
Implementation note
If you need strict OpenFeature conformance across multiple providers, put the translation layer in your application or shared platform package rather than coupling business code directly to Zenmanage SDK primitives.
Provider adapter sketch
typescript
import { Zenmanage, ConfigBuilder, Context } from '@zenmanage/sdk';
const zenmanage = new Zenmanage(
ConfigBuilder.create().withEnvironmentToken(process.env.ZENMANAGE_SERVER_KEY!).build()
);
export async function resolveBoolean(flagKey: string, userId: string, fallback = false) {
const context = Context.single('user', userId);
const flag = await zenmanage.flags().withContext(context).single(flagKey, fallback);
return flag.asBool();
}
Next step
Take the next integration step in your own stack.
Start with the quickstart that matches your runtime, then return to the reference pages when you need exact request and payload details.