Is your feature request related to a problem?
Customers want to react specifically to flag creation, for example to automatically apply default segment overrides to every newly created flag (a flag defaults to off for a given segment on creation). Today this isn't possible. The environment webhook fires on flag creation, but all four scenarios (creating a feature, updating a feature value/state, overriding for an identity, overriding for a segment) are sent with the same event_type: "FLAG_UPDATED", and the payload doesn't indicate which action occurred. A webhook consumer can't reliably tell a newly created flag apart from any other change, so it can't trigger creation-only automation.
Describe the solution you'd like.
Add a distinct event type for flag creation (e.g. FLAG_CREATED) on the environment webhook, and/or include the specific action in the payload so consumers can differentiate create vs value/state update vs identity override vs segment override. The immediate use case only needs reliable detection of flag creation to trigger automation that applies default segment overrides on new flags.
Describe alternatives you've considered
Org-level audit log webhook: fires on flag creation but sends every audit event to one endpoint with no filtering, so the consumer has to ingest and filter the whole org audit stream. Workable but noisy.
Terraform provider: for_each over the feature map to create a feature state per feature/environment/segment, but it only covers flags created through Terraform, and deleting an override in the UI causes Terraform to recreate it on the next apply (drift).
Release Pipelines: doesn't address defaults at creation; it moves a flag through stages with triggers and actions.
Additional context
This has come up from customers through support. The internal refactor in #5790 (centralizing feature_state webhooks under audit logs) may be a natural place to add the event-type distinction
Is your feature request related to a problem?
Customers want to react specifically to flag creation, for example to automatically apply default segment overrides to every newly created flag (a flag defaults to off for a given segment on creation). Today this isn't possible. The environment webhook fires on flag creation, but all four scenarios (creating a feature, updating a feature value/state, overriding for an identity, overriding for a segment) are sent with the same
event_type: "FLAG_UPDATED", and the payload doesn't indicate which action occurred. A webhook consumer can't reliably tell a newly created flag apart from any other change, so it can't trigger creation-only automation.Describe the solution you'd like.
Add a distinct event type for flag creation (e.g.
FLAG_CREATED) on the environment webhook, and/or include the specific action in the payload so consumers can differentiate create vs value/state update vs identity override vs segment override. The immediate use case only needs reliable detection of flag creation to trigger automation that applies default segment overrides on new flags.Describe alternatives you've considered
Org-level audit log webhook: fires on flag creation but sends every audit event to one endpoint with no filtering, so the consumer has to ingest and filter the whole org audit stream. Workable but noisy.
Terraform provider:
for_eachover the feature map to create a feature state per feature/environment/segment, but it only covers flags created through Terraform, and deleting an override in the UI causes Terraform to recreate it on the next apply (drift).Release Pipelines: doesn't address defaults at creation; it moves a flag through stages with triggers and actions.
Additional context
This has come up from customers through support. The internal refactor in #5790 (centralizing feature_state webhooks under audit logs) may be a natural place to add the event-type distinction