Flagship adds native support for nested objects and arrays in evaluation context

Flagship’s evaluation engine now accepts a full JSON structure as context, meaning you can send objects, arrays, and nulls directly when checking a flag. Engineers can reference those nested fields in targeting rules, removing the need to pre‑flatten user profiles or tag lists.

Structured context in the Workers binding

When a Cloudflare Worker calls the FLAGS binding, the third argument can contain any JSON shape. The following JavaScript example demonstrates a typical call:

const enabled = await env.FLAGS.getBooleanValue(
  "new-checkout",
  false,
  {
    targetingKey: "user-42",
    profile: { plan: "enterprise" },
    tags: ["beta", "early-access"]
  }
);

The profile object and tags array travel to the evaluation service unchanged, ready for rule evaluation.

Impact on targeting rules and rollouts

Targeting expressions can now address nested fields using dot notation. For example, a rule can combine profile.plan equals "enterprise" with tags has "beta" to enable a feature only for enterprise users who belong to the beta cohort. Array membership is expressed with the has and not_has operators.

Percentage rollouts can also reference a nested identifier such as profile.id, ensuring consistent bucket assignment across evaluations.

SDK and API changes

The structured context model is available through three entry points:

• The Workers binding, as shown above.
• The evaluation REST API, which now expects a JSON POST body containing the same structure.
• The OpenFeature SDKs for TypeScript, Python, and Go, starting with version 0.6.0. These SDKs automatically switch to POST when a request includes a structured context payload.

All three paths preserve the original JSON hierarchy, so downstream rule processing sees the exact shape you supplied.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Adopting the new context format reduces data‑massaging code in your Workers or backend services. Review existing flag rules to replace flattened keys with dot‑separated paths where appropriate. Verify that your OpenFeature SDK version meets the 0.6.0 threshold to benefit from automatic POST handling. Finally, test any percentage rollouts that rely on identifiers to confirm they still produce stable bucket assignments when the identifier moves from a top‑level key to a nested field.