How CtrlApp works
The mental model — an app registers devices, syncs a resolved state, and reads flags, controls, and a kill-switch decision.
Your app talks to the CtrlApp public REST API. Everything else — dashboard, targeting, audit — orbits around that one exchange.
The exchange in one picture
text
app / SDK CtrlApp public API
────────── ──────────────────
POST /sdk/v1/register ──► upsert device, return app config
POST /sdk/v1/session ──► block decision (kill-switch / force-update)
GET /sdk/v1/controls ──► server-resolved UI controls map
GET /sdk/v1/flags/ruleset──► feature-flag ruleset (evaluated locally)
POST /sdk/v1/events ──► analytics + delivery ack (batched)Three things you actually get
- Kill-switch & force-update — block a bad build in seconds, cached offline.
- Feature flags — boolean or multivariate, with targeting and % rollout.
- UI controls — server-owned text, images, colors, links, variants per key.
Where the data lives
Every resource is scoped to an App. An app has environments (typically Test and Production) and one or more publishable API keys. Devices identify themselves with a stable device_uid you generate on the client.
Note
For live updates, controls have an SSE channel — see Controls live stream — and every SDK also falls back to periodic delta polling and reads the offline cache first, so a killed app stays blocked even without a network.