OpenFeature specification
Go to file
Jonathan Norris 1e98b79719
docs(multi-provider): Document Track Method Support in Multi-Provider (#320)
## This PR

This PR updates the Multi-Provider documentation in the OpenFeature
specification to document the new `track` method support that was added
in [PR #1323](https://github.com/open-feature/js-sdk-contrib/pull/1323).

### 📚 New Documentation Sections

- **Track Method Support**: Added a section explaining how the
Multi-Provider implements tracking functionality
- **Introduction Section**: Updated use case examples to highlight
tracking capabilities
- **BaseEvaluationStrategy**: Added `shouldTrackWithThisProvider` method
to the abstract class

## Code Examples Added

```typescript
// Basic tracking usage
const multiProvider = new MultiProvider([
  { provider: new ProviderA() },
  { provider: new ProviderB() }
])

await OpenFeature.setProviderAndWait(multiProvider)
const client = OpenFeature.getClient()

// Track events across all ready providers
client.track('purchase', { targetingKey: 'user123' }, { value: 99.99, currency: 'USD' })
```

---------

Signed-off-by: Jonathan Norris <jonathan@taplytics.com>
2025-07-11 13:49:19 -04:00
.github/workflows chore: delete dupe CODEOWNERS 2025-04-24 11:06:29 -04:00
specification docs(multi-provider): Document Track Method Support in Multi-Provider (#320) 2025-07-11 13:49:19 -04:00
tools fix: typo in specification_parser (#288) 2025-01-02 10:23:19 -05:00
.gitignore docs: include STATIC and CACHED in provider reasons (#166) 2022-12-19 16:22:55 -05:00
.markdown-link-check-config.json Link check. 2022-05-27 16:49:50 -07:00
.markdownlint.yml chore: clarify eval details funcs/structs (#209) 2023-09-26 09:19:11 -04:00
.prettierrc.yaml No line wrapping 2022-05-31 15:46:27 -04:00
.specignore parser: add support for .specignore file 2022-05-06 11:10:50 -04:00
CODEOWNERS Add a codeowner, set TSC as the spec owner. (#308) 2025-05-13 17:01:37 -04:00
LICENSE Use Apache License v2 in the repository 2022-02-11 14:14:40 +01:00
Makefile fix: links and link checks (#172) 2023-01-12 12:04:32 -05:00
README.md docs: improve spec readme (#232) 2024-01-16 17:29:03 -05:00
package-lock.json chore(deps): update dependency prettier to v3.6.2 (#322) 2025-06-30 14:02:44 +00:00
package.json chore(deps): update dependency markdownlint-cli to ^0.44.0 (#291) 2025-04-24 11:21:40 -04:00
renovate.json chore: improve Renovate config (#231) 2024-01-16 08:56:35 -05:00
specification.json fix: correct shutdown points after status removal (#317) 2025-06-23 13:10:32 -04:00

README.md

OpenFeature Logo

OpenFeature Specification

Roadmap Contributing Slack CII Best Practices

OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution.

This repository describes the requirements and expectations for OpenFeature.

Design Principles

The OpenFeature specification must be designed with:

  • compatibility with existing feature flag offerings.
  • simple, understandable APIs.
  • vendor agnosticism.
  • language agnosticism.
  • low/no dependency.
  • extensibility.

SDKs and Client Libraries

The project aims to provide a unified API and SDK feature flag evaluation across popular technology stacks. The OpenFeature SDK provides a mechanism for interfacing with an external evaluation engine in a vendor agnostic way; it does not itself handle the flag evaluation logic.

An up-to-date SDK compatibility overview can be found here.

Tooling

This specification complies with RFC 2119 and seeks to conform to the W3C QA Framework Guidelines.

In accordance with this, some basic tooling (donated graciously by Diego Hurtado) has been employed to parse the specification and output a JSON structure of concise requirements, highlighting the particular RFC 2119 verb in question.

To parse the specification, simply type make. Please review the generated JSON files, which will appear as siblings to any of the markdown files in the /specification folder.

Style Guide

  • Use code blocks for examples.
    • Code blocks should be pseudocode, not any particular language, but should be vaguely "Java-esque".
  • Use conditional requirements for requirements that only apply in particular situations, such as particular languages or runtimes.
  • Use "sentence case" enclosed in ticks (`) when identifying entities outside of code blocks (ie: evaluation details instead of EvaluationDetails).
  • Do not place line breaks into sentences, keep sentences to a single line for easier review.
  • String literals appearing outside of code blocks should be enclosed in both ticks (`) and double-quotes (") (ie: "PARSE_ERROR").
  • Use "Title Case" for all titles.
  • Use the imperative mood and passive voice.