Flagsmith / Flagsmith/flagsmith

Add a distinct FLAG_CREATED webhook event (or include the action type in webhook payloads)

Open
#7,849 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
6.6k
Forks
567
Avg merge
1d 13h
Merged PRs (30d)
121

Description

### 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

Contributor guide

Open the contributing guide

Research direction

Start by reading the internal refactor in #5790 and tracing how feature-state changes are centralized under audit logs and emitted through the environment webhook. Identify where creation, value/state updates, identity overrides, and segment overrides become webhook events; done means consumers can reliably distinguish flag creation from the other actions.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.