Projects & Environments
FeatureSignals organizes feature flags into projects and environments, mirroring how most teams structure their applications.
Projects
A project represents a single application or service. Each project has its own set of flags, environments, and segments.
bash
curl -X POST https://api.featuresignals.com/v1/projects \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "Mobile App", "slug": "mobile-app"}'Environments
Environments represent deployment stages. Default environments created on registration:
| Environment | Slug | Color |
|---|---|---|
| Development | dev | |
| Staging | staging | |
| Production | production |
Per-Environment Flag States
The same flag can be:
- ON in
devwith a 100% rollout - ON in
stagingwith 50% rollout for testing - OFF in
production(not yet released)
API Keys
Each environment has its own API keys. There are two types:
| Type | Prefix | Use Case |
|---|---|---|
| Server | fs_srv_ | Backend services (full evaluation) |
| Client | fs_cli_ | Frontend/mobile apps (read-only flag values) |
Caution: The full API key is shown only once in the response. Store it securely.
Flag Promotion
Promote flag configurations from one environment to another:
bash
curl -X POST https://api.featuresignals.com/v1/projects/$PROJECT_ID/flags/my-flag/promote \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"source_env_id": "dev-env-id", "target_env_id": "staging-env-id"}'Promotion copies the enabled state, default value, targeting rules, and percentage rollout from the source to the target environment.