Skip to main content
A feature flag is a named, typed value. Your server reads it and decides what to do with it. Change one in the dashboard and every server reading it picks up the new value on its next refresh — no restart, no redeploy, no file edit.

No Restart Required

Flip a flag and live servers pick it up within seconds.

Typed Values

Booleans, strings, numbers, and arbitrary JSON — not just on/off switches.

Server-Only Secrets

Mark a flag server and it is never published to players’ clients.

Audit Log

Every change is recorded — who changed what, and when.

​
Types

A flag holds one of four value types. The type and the value are validated together, so a number flag can never end up holding a string.

​
Runtimes

Every flag also has a runtime, which says where it may be read: Your server holds the API key and is the trusted side, so it always receives every flag. The runtime decides whether a value may also be relayed to players. A server flag is never published to clients — reading one from a client behaves exactly like reading a flag that does not exist.
shared is the default. A flag is client-readable unless it says otherwise, so anything holding a secret (a webhook URL, a license key) must be created with runtime: "server".
There is no client-only runtime: a value a client can read is one the server has already been sent.

​
Keys

The key is the stable identifier your code reads a flag by.
​
string
required
Lowercase slug, 1–64 characters. Must start with a letter or number and may contain only lowercase letters, numbers, hyphens and underscores — ^[a-z0-9][a-z0-9_-]*$.
Keys are immutable. Servers reference a flag by key, so renaming one would silently orphan every server reading it. The name and description are free-form and can be changed at any time.

​
Limits

The allowance is a perk of being a paying customer — any active subscription raises it, not a flags-specific one. Every flag is shipped in the configuration payload each server polls, so the cap also bounds payload size.

​
Locked flags

If a subscription lapses while you hold more flags than the free allowance, the flags beyond it become locked. Oldest flags stay editable; the newest ones lock.
A locked flag keeps serving its published value, so a billing lapse never changes behaviour on a live server. Only editing it is blocked — archiving and deleting stay allowed, since removing a flag is how you get back under the allowance.
Locked flags are reported by GET /flags/quota, and every flag in a list response carries a locked boolean.

​
Archiving vs. deleting

Archiving is the safe way to retire a flag. Reads of a missing flag fall back rather than throwing, so archiving one can never break a running server.

​
How values reach your server

1

You change a flag

The API writes it to the database and republishes your organization’s configuration payload to the edge cache.
2

Your server polls

Servers request GET /flags/config with the ETag they already hold. An unchanged configuration is answered with a 304 and no body.
3

Your server publishes to clients

The CFX SDK writes the shared flags to GlobalState, which the game replicates to every player. Server-only flags never leave the server.
The ETag is a hash of the flags the payload contains, so an unchanged set of flags always produces the same one — and an edit that is later undone stops looking like a change.

​
Audit log

Every mutation appends an entry recording the actor, the action, and the full before/after state. Flags are the kind of thing people flip during an incident and then disagree about afterwards. Read it with GET /flags/audit.

​
Permissions

An API key used by a game server only needs FLAGS_READ — that is enough to poll the configuration endpoint.

​
Start reading flags

CFX SDK

Read flags from FiveM/RedM server and client scripts

NUI SDK

Read flags from your NUI interfaces

Node.js SDK

Read and manage flags from any Node.js app

API Reference

The REST endpoints behind every SDK