Skip to main content

Documentation Index

Fetch the complete documentation index at: https://omniflagsdoc.omniretail.app/llms.txt

Use this file to discover all available pages before exploring further.

Resources in OmniFlags are organised across three levels: projects, environments, and applications.

​
Projects

A project is a namespace for a set of related flags, typically a service, product area, or team. Every project has a key (e.g. checkout, product-listing). The key is set at creation and cannot be changed. It is the first segment of every flag reference in code: 
checkout.charge-delivery-fee
product-listing.show-promo-products
agent-app.enable-bulk-actions
mos.new-order-flow
Flags, environments, segments, and change history are all scoped per project. Members can be granted access at the project level independently of other projects.

​
Environments

Environments represent your deployment stages: development, staging, production, or whatever your workflow uses. Each flag is configured independently per environment. The same flag key can have completely different rollout percentages, targeting rules, and default values in each environment: 
checkout.charge-delivery-fee
├── development  disabled
├── staging      enabled, targeting: country = "Nigeria", rollout 10%
└── production   enabled, targeting: country = "Nigeria", rollout 100%

agent-app.enable-bulk-actions
├── development  enabled, rollout 100%
└── production   enabled, rollout 5%
The SDK key you use when initialising the provider determines which environment’s configuration is fetched. All flag evaluation for that SDK instance reflects that environment’s settings only.

​
Approvals

Environments can require approvals before flag changes take effect. When enabled, a submitted change enters a pending state and must be approved by a configured number of reviewers before it is published. This is typically enabled on production environments. Approval settings are configured per environment under Settings → Environments within a project.

​
Applications and SDK keys

An application represents a consumer of the flag distribution API: a web app, mobile app, backend service, or any other process that evaluates flags. Applications are managed at the organisation level under Applications in the dashboard. Each application is granted access to one or more project environments. Each grant produces an SDK key, a credential scoped to that application and environment pairing: 
Application: "ROS PWA"
├── checkout  /  production  →  pk_live_abc...
└── checkout  /  staging     →  pk_live_def...

Application: "ROS Native"
└── product-listing  /  production  →  pk_live_ghi...

Application: "Order Service"
└── checkout  /  production  →  pk_live_jkl...
Pass the SDK key to the provider when initialising the SDK: 
<OmniFlagsProvider sdkKey="pk_live_...">
  <App />
</OmniFlagsProvider>

​
Key management

SDK keys are shown once in the dashboard when created. Store them in environment variables and treat them as secrets. They grant read-only access to the flag snapshot. They cannot create, modify, or delete any resources. To rotate a key: revoke it and generate a new one. Instances holding the revoked key continue serving from their cached snapshot until their next refresh attempt, at which point the request will fail and the SDK will surface the error via its status hooks.