Create a single feature
Creates a new Feature Flag. The caller needs Create access in its Project, plus Publish access for any environment the Feature Flag starts enabled in — one that starts disabled everywhere needs Create alone. Rules are supplied as a top-level rules array; each rule includes allEnvironments / environments scope fields.
Config-backed features (Config mode)
A JSON feature can be backed by a shared config — the config supplies the base JSON value and schema, and the feature’s rule values become override patches merged on top (nested objects deep-merge; arrays and scalars replace). The default value is exactly a config with no overrides (see below). Config backing is set exclusively through dedicated fields — never a raw $extends: ["@config:…"] inside a value string (that is rejected). @const: references inside values still work.
- Top-level (
baseConfig): setvalueType: "json"andbaseConfig: "<configKey>"to put the Feature Flag in Config mode. The config must be live. This is the family root and the base the default value patches. - Default value: unlike rules, the default is exactly a config with no overrides of its own — send
defaultValue: "{}"to usebaseConfig. To resolve the default to a descendant ofbaseConfiginstead, setdefaultValueConfigto that descendant’s key (it must be withinbaseConfig’s family); omit/null to usebaseConfigdirectly. - Rules & experiment variations: each carries its own
configfield naming the family config that value patches (omit/null to patch the base).valueis the override patch.
Example:
{
"id": "checkout-config",
"valueType": "json",
"baseConfig": "purchase-flow",
"defaultValue": "{}",
"rules": [
{ "type": "force", "config": "purchase-flow-vip", "value": "{\"maxItems\": 20}", "allEnvironments": true }
]
}
Authorizations
If using Bearer auth, pass the Secret Key as the token:
Query Parameters
Deprecated — pass skipSchemaValidation in the request body instead.
"true"Deprecated — pass ignoreWarnings in the request body instead.
"true"Body
A unique key name for the feature. Feature keys can only include letters, numbers, hyphens, and underscores.
1The data type of the feature payload. Boolean by default.
boolean, string, number, json Default value when feature is enabled. Type must match valueType. In Config mode (baseConfig set) the default must be exactly a config with no overrides: send "{}" to use baseConfig, or set defaultValueConfig to point at a descendant.
Description of the feature
10000The userId or email address of the owner. If an email address is provided, it will be used to look up the userId of the matching organization member. If an ID is provided, it will be validated as existing in the organization. Optional when authenticating with a Personal Access Token (PAT): when omitted, the owner defaults to the PAT's user. Required when authenticating with an organization secret API key (which has no associated user): omitting it fails with a 400.
An associated project ID
Make this feature discoverable in — and served to — every project, beyond its primary project. Governance/approvals stay with project.
Secondary project IDs this feature is targeted in and served to, beyond its primary project. Governance/approvals stay with project.
Key of the config backing this flag ("Config mode"). Requires valueType: "json" and a live config. The config supplies the base JSON and schema; defaultValue and rule values are override patches on top. null or omitted for a plain flag.
Optional. A config within baseConfig's family that the default value resolves to instead of baseConfig itself. null or omitted means the default is baseConfig. The default is exactly this config and carries no overrides of its own.
List of associated tags
Feature rules. Each rule carries its own environment scope via allEnvironments / environments.
- Option 1
- Option 2
- Option 3
- Option 4
Per-environment enabled state. V2 rules are specified on the top-level rules field.
Feature IDs. Each feature must evaluate to true
Use JSON schema to validate the payload of a JSON-type feature value (enterprise only).
Set to true to acknowledge the warnings listed in a blocked response and continue. This covers experiment guards, locked dependents, and references affected by an archive. When the organization treats schema failures as warnings, it also covers schema and invariant warnings. It never bypasses a rejected Custom Hook. On revision publish endpoints, it can also force-publish an out-of-date draft when the caller has Bypass draft approvals access.
Set to true to publish despite schema validation errors, failed invariants, or schema changes that invalidate dependent resources. This does not bypass a rejected Custom Hook; use skipHooks for that. The caller must have Bypass draft approvals access for Feature Flags, Configs, and Constants in every Project. Otherwise, this field is ignored.
Set to true to publish despite a Custom Hook rejection. This does not bypass schema validation; use skipSchemaValidation for that. The caller must have Bypass draft approvals access for Feature Flags, Configs, and Constants in every Project. Otherwise, this field is ignored.
Response
Resource created

