Platform architecture
How FeatureToggle is built and how the client application connects to it.
You manage features in the dashboard (app.featuretoggle.com). The client application reads them through the public feature API (https://api.featuretoggle.com) using the SDK or direct HTTP calls. There is no write API for customer apps. Feature changes always go through the dashboard.
At a glance
| Surface | Who uses it | What it does |
|---|---|---|
| Dashboard | Organization members | Feature definitions, Overrides, API keys, environments, and billing |
| Feature API | Client application | Read resolved feature values for one environment (read-only) |
| SDK | Client application | Caches features locally, handles auth headers, live updates via SSE |
The dashboard and the feature API share the same underlying data store. The client app never talks to the dashboard directly.
How the client app reads features
Typical flow:
- Client code calls the SDK (
isEnabled,getValue, etc.). - The SDK requests features from
api.featuretoggle.comusing the environment API key. - FeatureToggle resolves each feature for that environment (defaults plus any per-environment overrides).
- The SDK keeps features in memory and refreshes when they change.
See Caching and syncs for when requests reach origin vs. are served from cache.
Live updates
When you toggle a feature in the dashboard, connected SDK instances can receive a push notification over Server-Sent Events (SSE) and refresh immediately.
The client app can also refresh on tab focus or at SDK startup. With default stream: "auto", no background poll timer is needed. If you use stream: "off" (tests or no SSE), the SDK can poll on an interval instead. See SDKs.
Public API summary
Read-only endpoints only:
| Endpoint | Method | Purpose |
|---|---|---|
/v1/features | GET | All enabled features for the API key's environment |
/v1/features/:key | GET | One enabled feature by key |
/v1/features/stream | GET | Live SSE stream for feature changes |
Full reference: Feature API
API keys
| Prefix | Environment | Use for |
|---|---|---|
ft_test_ | development | Local development (loopback only, not LAN IPs) |
ft_live_ | staging, production | Deployed applications |
- One API key is scoped to one environment in one project.
- Keys grant read access only to enabled features for that environment.
- Pass the key as
Authorization: Bearer ft_...on every API request.
Details: Security · Core concepts
Domains
| URL | Purpose |
|---|---|
| featuretoggle.com | Marketing site |
| app.featuretoggle.com | Dashboard |
https://api.featuretoggle.com | Public feature API |
All traffic is served over HTTPS with managed TLS certificates.
What runs behind the API
FeatureToggle is hosted on AWS. At a high level:
- Edge network — low-latency responses and reduced origin load for unchanged feature data.
- Feature API service — validates the API key, resolves features, returns JSON or
304. - Managed database — single source of truth for all feature state. Caches are accelerators only.
This stack is designed for read-heavy workloads: many apps streaming or refreshing, few dashboard writes.
Security model
| Surface | Authentication | Access |
|---|---|---|
| Feature API | API key | Read features for one environment |
| Dashboard | Signed-in user session | Manage the organization's projects |
We do not expose project management, key administration, or dashboard settings on the public API.
SDK packages
| Package | Use for |
|---|---|
| featuretoggle-sdk-typescript | Browser and Node: SSE, caching |
| featuretoggle-sdk-typescript/server | Server-side reads (SSR, API routes, middleware) |
| featuretoggle-sdk-react | React hooks and provider |
Details: SDKs