Feature Flags

Feature flags let you control the rollout of features without deploying new code. Bridge Feature Flags (FF 2.0) uses a three-state model — a flag is off (off for everyone), on (on for everyone), or on-with-rule (on for users matching a rule, with explicit per-branch return values). Rules target users, tenants, devices, or custom attributes, and flags return multi-type values (boolean, string, number, or JSON), not just on/off.

For the conceptual guide, the SDKs, and how to configure flags in the dashboard, see the Feature Flags guide. This page documents the REST evaluation API only.

The evaluation endpoints below are public and require no authentication — they can be called directly from server-side code or any client without a Bridge SDK. There is no public REST API for managing flags (see Managing flags).

Evaluation Context

Most apps use a framework SDK which evaluates flags locally (an in-memory rule lookup, no network round-trip per eval) and only needs these REST endpoints when you have no SDK — for example server-side evaluation from a language Bridge doesn’t ship an SDK for. When you do call REST, you supply the evaluation context in the request body.

Internally, FF 2.0 evaluates against a { identity, attributes } context. The structured object below is the REST mapping of that model: user.id / tenant.id map to the bucketing identity, and the remaining fields (user.role, tenant.plan, device.key, custom.*, …) become attributes your rules can target. You can send either this structured object or a raw accessToken (JWT), from which Bridge resolves the user/tenant attributes.

{
    "user": { "id": "63d2ab029e23f80afb0daf97", "role": "ADMIN", "name": "John Doe", "email": "john@doe.com", "key": "custom" },
    "tenant": { "id": "63d2ab029e23f80afb0daf90", "plan": "PREMIUM", "name": "My Workspace", "key": "custom" },
    "device": { "key": "iphone" },
    "custom": { "property1": "value1" }
}

All context fields are optional — include only what your flag rules reference.

Paths. The canonical evaluation paths are shown unversioned (/cloud-views/flags/…) and resolve as-is. Other FF 2.0 routes are URI-versioned with a v1 prefix (/v1/…); the unversioned legacy form of those also still resolves. The public API base is https://api.thebridge.dev.

---

Evaluate a Flag

Evaluate a single feature flag for a given context. This endpoint is public and does not require authentication.

Use GET when you have no targeting context (anonymous, default evaluation), and POST when you want to send an evaluation context. Both return the same response shape.

HTTP Request

GET https://api.thebridge.dev/cloud-views/flags/evaluate/APP_ID/FLAG_KEY

POST https://api.thebridge.dev/cloud-views/flags/evaluate/APP_ID/FLAG_KEY

Path Parameters

Parameter	Type	Required	Description
APP_ID	string	Required	Your application ID
FLAG_KEY	string	Required	The unique key of the flag to evaluate

Body Parameters (POST)

Parameter	Type	Required	Description
user	object	Optional	User context — id, role, name, email, key
tenant	object	Optional	Tenant context — id, plan, name, key
device	object	Optional	Device context — key
custom	object	Optional	Arbitrary key-value pairs for custom targeting rules
accessToken	string	Optional	A JWT access token. Can be sent instead of the context object

Response HTTP 200

HTTP 200 — Returns the evaluation result.

Response Fields

Parameter	Type	Required	Description
value	boolean | string | number | object	Optional	The typed flag result. The type is inferred from the flag's configured value type. Omitted only on a hard error where the SDK would fall back to your default
enabled	boolean	Required	Legacy boolean convenience kept for backward compatibility. true/false regardless of the flag's value type
variantIndex	number	Optional	Which rule branch matched: -1 = the otherwise / default value, >= 0 = the zero-based index of the matched branch

Request example

cURL ▼

Copy

curl --request POST 'https://api.thebridge.dev/cloud-views/flags/evaluate/APP_ID/FLAG_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
  "user": { "id": "63d2ab029e23f80afb0daf97", "role": "ADMIN" },
  "tenant": { "id": "63d2ab029e23f80afb0daf90", "plan": "PREMIUM" },
  "device": { "key": "iphone" }
}'

Response example (boolean flag):

{
    "enabled": true,
    "value": true,
    "variantIndex": 0
}

Response example (string flag — multi-type value):

{
    "enabled": true,
    "value": "dark",
    "variantIndex": 1
}

A number or json flag returns value typed accordingly (e.g. "value": 50 or "value": { "window": 60, "max": 100 }). For non-boolean flags, enabled is the legacy boolean view of the result; read value for the typed result.

▶ POST Try it out

POST https://api.thebridge.dev/cloud-views/flags/evaluate/:APP_ID/:FLAG_KEY

APP_ID URL parameter Your application ID

FLAG_KEY URL parameter The unique key of the flag

Request Body (JSON) { "user": { "id": "63d2ab029e23f80afb0daf97", "role": "ADMIN" }, "tenant": { "id": "63d2ab029e23f80afb0daf90", "plan": "PREMIUM" }, "device": { "key": "iphone" } }

Send Request Copy as cURL

---

Evaluate Flags in Bulk

Evaluate all flags for a given context in a single request. This endpoint is public and does not require authentication.

HTTP Request

POST https://api.thebridge.dev/cloud-views/flags/bulkEvaluate/APP_ID

Path Parameters

Parameter	Type	Required	Description
APP_ID	string	Required	Your application ID

Body Parameters

Parameter	Type	Required	Description
user	object	Optional	User context — id, role, name, email, key
tenant	object	Optional	Tenant context — id, plan, name, key
device	object	Optional	Device context — key
custom	object	Optional	Arbitrary key-value pairs for custom targeting rules
accessToken	string	Optional	A JWT access token. Can be sent instead of the context object

Response HTTP 200

HTTP 200 — Returns an object with a flags array. Each entry pairs a flag key with its evaluation (the same { enabled, value, variantIndex } shape as a single evaluation).

Request example

cURL ▼

Copy

curl --request POST 'https://api.thebridge.dev/cloud-views/flags/bulkEvaluate/APP_ID' \
--header 'Content-Type: application/json' \
--data-raw '{
  "user": { "id": "63d2ab029e23f80afb0daf97", "role": "ADMIN" },
  "tenant": { "id": "63d2ab029e23f80afb0daf90", "plan": "PREMIUM" },
  "device": { "key": "iphone" }
}'

Response example:

{
    "flags": [
        {
            "flag": "iphone-feature",
            "evaluation": {
                "enabled": true,
                "value": true,
                "variantIndex": 0
            }
        },
        {
            "flag": "checkout-cta",
            "evaluation": {
                "enabled": true,
                "value": "Pay now",
                "variantIndex": -1
            }
        }
    ]
}

▶ POST Try it out

POST https://api.thebridge.dev/cloud-views/flags/bulkEvaluate/:APP_ID

APP_ID URL parameter Your application ID

Request Body (JSON) { "user": { "id": "63d2ab029e23f80afb0daf97", "role": "ADMIN" }, "tenant": { "id": "63d2ab029e23f80afb0daf90", "plan": "PREMIUM" }, "device": { "key": "iphone" } }

Send Request Copy as cURL

---

Managing flags

There is no public REST API for creating, editing, or deleting flags — the FF 2.0 management surface lives elsewhere:

• In the Bridge dashboard. Flags and their rules (the three-state model, branches, conditions, rollout percentage, and value type) are configured visually in the Bridge admin UI. This is where you flip a flag off/on/on-with-rule, build targeting rules, and set the value each branch returns.
• By auto-discovery. You don’t have to pre-register a flag. The first time your code evaluates an unknown key — via an SDK flag("my-key", default) call or one of the evaluation endpoints above — the key appears in the dashboard flags list with a “Discovered” badge, ready to configure. See Targeting & Attributes.

The legacy 1.x flag- and segment-management REST endpoints (/admin/flags/*) are not part of the FF 2.0 public developer surface. Segments have been replaced by the three-state model with inline rules; flag administration happens in the dashboard behind an admin session, not via x-api-key.

---

SDK telemetry & live updates

When you use a framework SDK, it talks to a few additional endpoints on your behalf. You never call these directly — they are listed here only so the traffic is recognizable. All require the app x-api-key header and return HTTP 202:

Endpoint	Purpose
POST /v1/flags/eval-events	Batched evaluation telemetry (per-(identity, flag, value) counters), flushed on a timer.
POST /v1/flags/discover	First-sighting auto-discovery of unknown flag keys, attribute keys, and entitlement keys.
POST /v1/flags/call-sites	Call-site fingerprints powering the “where used in code” view.

To receive live rule updates (a flag saved in the dashboard reaches connected apps in ~1 second), the SDK bootstraps a live channel via GET /v1/realtime/config and POST /v1/realtime/authorize, then subscribes over WebSocket. This too is handled entirely by the SDK.

These flows have independent failure budgets: telemetry and discovery never block evaluation, and a dropped live channel freezes flags on their last-known values until reconnect. See the Observability guide for the developer-facing controls.