FTF at a glance

Open standards

OpenFeature, in any language

Your applications depend on OpenFeature, the CNCF's vendor-neutral feature-flag API — not on FTF. FTF implements OpenFeature's Remote Evaluation Protocol (OFREP), so Java, .NET, Go, Python, Node and browser applications use OpenFeature's own SDKs, with no FTF library to adopt, version or patch.

Guidewire InsuranceSuite has no OpenFeature SDK; FTF's design gives it its own integration, applying the same rules — FTF GW client.

What the open standard changes for your architecture

Any language

No client per platform

OpenFeature already maintains SDKs and OFREP providers for the mainstream languages. A new platform needs no work from us or from you — just configuration.

No lock-in to a vendor

Switch vendor, keep your code

FTF can sit in front of LaunchDarkly or ConfigCat. Your applications only ever talk to FTF, so moving between them is a change inside FTF, not a project in every application.

No lock-in to FTF

Leaving is configuration

Your code calls OpenFeature, not FTF. Replacing FTF means configuring a different OpenFeature provider — the toggle checks in your code stay as they are.

Consistency

One answer, everywhere

Every way of evaluating a toggle — FTF's service, OFREP and the offline evaluators — is held to one shared set of test cases, so a toggle never behaves differently by platform.

What FTF implements

OpenFeature Remote Evaluation Protocol 0.4.0. Tested end to end with OpenFeature's own Python, Node and browser providers.

  • One flag — POST /ofrep/v1/evaluate/flags/{key}, the context sent with each call; for server-side providers.
  • All of an application's flags — POST /ofrep/v1/evaluate/flags, for browser providers. It returns an ETag, and 304 Not Modified when nothing has changed, so polling is cheap.
  • The key is the toggle's full name, e.g. acme.web.new_checkout.
  • Authentication — the environment's client key, as X-API-Key or a bearer token. The application is named in X-FTF-Application, or fixed by an application-restricted key.
  • Context — strings, numbers and booleans. Numbers still compare as numbers (claimAmount > 10000). targetingKey is an ordinary attribute, e.g. the key of a percentage rollout.
  • Reasons — STATIC, TARGETING_MATCH, SPLIT (percentage rollout) and DISABLED, for your logs and analytics.
  • An unknown toggle is FLAG_NOT_FOUND, so the SDK falls back to the default written in your code.
  • Browsers are answered across origins only for application-restricted keys, and only for evaluation.

What it doesn't do (yet)

  • Boolean toggles only. FTF's toggles are on/off with attributes; string, number and object flags aren't part of FTF's model.
  • Polling, not streaming. OFREP's optional event streams aren't offered yet; browser providers poll, and the ETag keeps that light.
  • Releases aren't flags. Applications ask about features; a release switches its features on together inside FTF.
  • Java offline evaluator is source code today, not yet a published library.

What an OpenFeature provider sends

curl $FTF_URL/ofrep/v1/evaluate/flags/acme.quotes.new_rating \ -H "X-API-Key: $FTF_CLIENT_KEY" \ -H "X-FTF-Application: quotes" \ -H "Content-Type: application/json" \ -d '{"context": {"targetingKey": "P-10042", "state": "NSW", "premium": 1850}}' # {"key": "acme.quotes.new_rating", "value": true, # "reason": "TARGETING_MATCH", "variant": "on", "metadata": {}}

In code, it's OpenFeature's usual one line, e.g. getBooleanValue("acme.quotes.new_rating", false, context). A JavaScript example is on the developers' page.

One set of test cases for every evaluator

A toggle that is on for a customer in one application must be on for them in every application. FTF keeps one shared file of evaluation cases, and every evaluator must give every expected answer: FTF's service, its OFREP endpoint, and the JavaScript, Python and Java evaluators. A change to how toggles evaluate starts with a new case, never with one implementation.

The cases pin down exactly the details implementations tend to disagree on:

  • What counts as a number — 1e4 yes; Infinity, 1_000 and hex no.
  • Lists are case-insensitive and ignore spaces; an empty list restricts nothing.
  • A percentage rollout puts the same customer in the same bucket in every language.
  • A feature in a release is on only when the release and the feature are both on.
  • A misconfigured attribute is skipped the same way everywhere — never an error that takes other toggles down with it.
  • Only a real true switches anything on; the text "true" doesn't.

See it with your own stack

The trial gives you an environment and a key: point an OpenFeature SDK in the language you use at it and switch a toggle.

Start a free trial Integration patterns