SDKs overview
feat ships first-party SDKs for the runtimes most teams use, plus an OpenFeature provider for the web. Every SDK evaluates flags locally against a polled datafile; flag reads do not make a network call.
Pick by runtime
Section titled “Pick by runtime”| Runtime | Package | API key type |
|---|---|---|
| Node.js, Bun, Deno (server) | @feathq/js-sdk | Server key (feat_sdk_…) |
| Browser JavaScript | @feathq/web-sdk | Client-side ID (feat_cs_…) |
| Go | github.com/feathq/go-sdk | Server key (feat_sdk_…) |
| Python | feat-sdk | Server key (feat_sdk_…) |
| Ruby | feat-sdk (gem) | Server key (feat_sdk_…) |
| Any web app using OpenFeature | @feathq/openfeature-web | Client-side ID (feat_cs_…) |
Server SDKs use a server key. The browser SDK uses the public client-side ID.
What every SDK shares
Section titled “What every SDK shares”- Local evaluation. The SDK fetches the datafile once at start, then polls for updates. Flag reads run in-process. There is no per-evaluation network call.
- Edge-served datafiles. Datafiles are served from feat’s edge so polls hit a point of presence close to your server, not a single origin.
- ETag-aware polling. Unchanged datafiles return a
304 Not Modified. Default poll interval is 30 seconds; configurable down to 5 seconds. - Identical semantics. The
@feathq/feat-evalpackage is the reference engine. The Go, Python, and Ruby SDKs port the same evaluation algorithm bit-for-bit. The same context, the same datafile, and the same flag key always give the same result, regardless of language. - Same API shape. Every SDK exposes
getBooleanValue,getStringValue,getNumberValue,getObjectValue(and a richerevaluatethat also returns the reason). The default-value-first argument order matches OpenFeature.
What differs
Section titled “What differs”- Browser SDK evaluates synchronously after
ready()because every flag is pre-evaluated against the current context into a map. Server SDKs are async by convention but the evaluation itself is also in-process. - JavaScript family ships an OpenFeature provider. Go, Python, and Ruby do not yet.
OpenFeature
Section titled “OpenFeature”feat is compatible with OpenFeature, the CNCF standard for feature flags. If you use OpenFeature already, swap in the feat provider; if you do not, using OpenFeature is the route to stay vendor-portable. See OpenFeature.
Datafile format
Section titled “Datafile format”The wire format is documented at Datafile format. You only need this if you are writing a custom SDK or a tool that consumes the file directly.
Reporting and metrics
Section titled “Reporting and metrics”The SDKs do not send evaluation events back to feat by default; the entire context lives on your machine and the dashboard has no per-evaluation telemetry. If you need to count exposures or correlate with your analytics tool, hook the SDK’s change event (or wrap the evaluate call) and push events to your own pipeline.