Skip to main content
The Evaluation API is the server-side surface that SDKs and direct HTTP callers use to resolve flags at runtime. It is authenticated with an environment-scoped SDK key sent in the Authorization: Bearer header.

Authentication

All evaluation endpoints require an SDK key issued for the target environment. Send it in the Authorization header:
The server hashes the key with SHA-256 and looks up the environment. The plaintext key is never stored — only the hash is persisted. If the environment is revoked or the key doesn’t match, you get 401 Unauthorized.
Some endpoints also accept sdkKey in the request body for backward compatibility with older clients. When both are present, the Authorization header takes precedence. New integrations should rely on the header only.

Endpoints

Evaluate a single flag

Resolves one flag for a given context.
Response 200 OK:

Evaluate multiple flags (batch)

Evaluate up to 100 flags in a single request. Results are returned in the same order as the evaluations array.
Response 200 OK:
A single unknown flag key in a batch does not fail the whole request — that entry returns { "enabled": false, "reason": "flag_disabled" } while the rest evaluate normally.
Maximum 100 evaluations per request. The evaluations array must contain at least one item.

Fetch flag configurations

Fetches full flag configurations (rules, rollout, enabled state) for caching. This is what the official SDKs call internally during initialize() and on each poll cycle.
If keys[] is omitted, all active flags for the environment are returned. Response 200 OK:
ETag support: The endpoint returns an ETag header. Send it back with If-None-Match on subsequent polls to avoid re-downloading unchanged configs:
If nothing changed, the server returns 304 Not Modified with no body. Always store and send the returned ETag.

Evaluation reasons

Context attributes

Pass as much context as available for targeting rules and percentage rollouts:

Error reference