Feature Variants

Feature variants assign a user (or targeting context) to a named variation of a flag — for example control vs treatment — with an optional configuration payload.

Toggly uses two evaluation models, depending on the SDK:

Model	Who	How assignment works
Catalog-local	Backend SDKs (.NET, Python, Go, Java, Ruby, Node, NestJS, Rust, Elixir)	Definitions include variants + allocation. The SDK assigns locally (user → group → percentile → defaults).
Evaluated-variants	Client / edge SDKs (JS, React, Vue, Svelte, mobile, …)	Opt in with enableVariants / enable_variants. The SDK fetches evaluated-variants-signed — the server already resolved the assignment for the identity.

Catalog-local (backends)

• One definitions fetch (definitions / definitions-signed).
• Boolean isEnabled stays filter-based on the catalog.
• getVariant / getVariantValue (or language equivalents) run the allocator against the same catalog using UserId + Groups.
• Identity: prefer ambient HTTP/session or config/setIdentity, then getVariant(key) — not a hand-built identity on every call. Precedence: per-call override → ambient → config/setIdentity → empty.
• Percentile hashing uses SHA-256 over {userId}\n{hint} (optional allocation seed, otherwise allocation\n{featureKey}).
• No enableVariants toggle and no second HTTP rail on these SDKs.

See the per-SDK docs (for example .NET, Java, Python, Go) for API names.

Evaluated-variants (clients)

• Opt in with enableVariants (default off).
• When enabled, the client calls evaluated-variants-signed (often instead of or in addition to boolean evaluated endpoints, depending on the SDK).
• getVariant returns the server-assigned name + configurationValue.

What not to confuse

• Telemetry usage/view variant labels are event tags, not assignment APIs.