Create a single feature
Deprecated. Use POST /v2/features instead.
Authorizations
If using Bearer auth, pass the Secret Key as the token:
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) this is the JSON override patch merged on top of the config.
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. Requires the targetFeatures permission (FlagsTarget policy) unscoped to any project. Governance stays with project.
Secondary project IDs this feature is targeted in and served to, beyond its primary project. Adding a project requires the targetFeatures permission (FlagsTarget policy) in that project. Governance stays with project.
Key of the config backing this flag ("Config mode"). Requires valueType: "json" and a live config; defaultValue and rule values become override patches on top. null or omitted for a plain flag.
List of associated tags
Settings for each environment, keyed by environment ID. Any environment you leave out is enabled or disabled per that environment's "Default state for new features" setting.
Feature IDs. Each feature must evaluate to true
Use JSON schema to validate the payload of a JSON-type feature value (enterprise only).
Comment to record on the feature's initial revision. Defaults to an empty comment.
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

