Skip to content

Contexts

A context describes an attribute that the SDK passes when evaluating a flag. Context definitions are optional — the SDK works without them. They exist to make rule configuration in the dashboard easier: with type hints, value whitelists, and typo protection.

Context Definitions

A context definition describes an attribute: its key, data type, and validation mode.

FieldPurposeExample
nameHuman-readable name"Country"
keyMachine key (used as field in constraints)country
typeData type: string, number, time, semverstring
isStrictEnforce a whitelist of allowed valuestrue

Value Whitelist

A context can be configured with a whitelist of allowed values. This is useful when you want to restrict the choices when configuring rules in the dashboard — for example, preventing someone from typing usa instead of US. With the whitelist enabled, only the predefined values are available in constraints and segments.

If you don't need a whitelist — simply leave it off, and any value can be entered when configuring rules.

Context Types & Operators

The context type determines how comparison operators interpret the value:

OperatorDescriptionstringnumbertimesemverExample
inMatches a value from the listcountry in [US, CA]
not_inNot in the listplan not_in [free]
eqEqualsage eq 18
neNot equalsplan ne free
gtGreater thanversion gt 2.0
gteGreater than or equalage gte 21
ltLess thanpriority lt 5
lteLess than or equalretries lte 3
containsContains substringemail contains @corp.com

Using Contexts in Code

Contexts are passed to the SDK when evaluating a flag:

java
MozhnoContext ctx = MozhnoContext.builder()
    .userId("user-123")
    .addProperty("country", "US")
    .addProperty("plan", "premium")
    .build();

boolean enabled = client.isEnabled("new-checkout", ctx);

The country and plan attributes can be defined as context definitions for easier rule configuration in the dashboard, but the SDK may pass any attributes regardless.

What's Next

Released under the AGPL v3.0 License.