You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Filter feature flags by group type in SDK and /feature_flags endpoint #110
We are using PostHog feature flags with group analytics to manage per-project feature toggles in our application. We have a project group type and want to allow users to opt-in/out of features for their specific project.
Current Behavior
When calling get_all_flags with a groups parameter, PostHog returns all feature flags regardless of their targeting type - person-based flags, group-based flags of all group types, etc.
client.get_all_flags(distinct_id,groups: {project: "project-uuid-here"})# Returns ALL flags: person-based, project-group, space-group, etc.
The groups parameter serves as an evaluation context, not as a filter. There seems to be no way to retrieve only the flags that target a specific group type.
Expected Behavior
It would be useful to have the ability to filter the response to only include flags that match a specific group type. For example:
client.get_all_flags(distinct_id,groups: {project: "project-uuid"},filter_by_group: :project# only return flags associated with a "project-uuid")
Use Case
We have a dashboard where users manage features for their project. We need to display only the feature flags relevant to that project's group type, not person-level flags or flags targeting other group types. Currently, the only workaround I can think of:
Using a naming convention/prefix to identify flags by group type
Making a separate REST API call to /api/projects/{id}/feature_flags/ to fetch flag definitions with metadata, then cross-referencing
Both might work (I have not yet verified the 2nd flow), but feel like they shouldn't be necessary given that the flag definitions already contain this information.
Additional Context
This also relates to the early access feature management not supporting groups. For applications that need organization/project-level feature opt-in (rather than individual user opt-in), the current tooling requires significant workarounds.
Short answer: no, this isn't possible today, and to answer @marandaneto, the API doesn't support filtering by group type. The groups parameter is only an evaluation context. The /flags response returns each flag's value/variant with no group-type metadata attached, so there's nothing in that payload to filter on.
Worth calling out why evaluating with groups doesn't already give you this: flags targeting other group types do come back as false (you're not passing those groups), so they're effectively neutralized. But person-based flags still evaluate against the distinct_id and can return true, and your own project flags that are currently off return false. So the value alone can't tell "not a project flag" apart from "a project flag that's off." Distinguishing those needs the flag's aggregation_group_type_index, which /flags doesn't return.
To support this properly we'd need to update the /flags endpoint to include the group type and/or accept a group-type filter. We wouldn't want to build it as an SDK-only feature on top of local evaluation, because get_all_flags has to behave the same whether or not a personal API key is configured. Implementing it only for the local-eval path would mean the same call returns different results depending on your setup, which we don't want.
In the meantime, your option 2 works today. The flag definitions at /api/projects/{id}/feature_flags/ include aggregation_group_type_index on each flag's filters, so you can fetch those once and use them to filter the results of get_all_flags by group type yourself.
There are other types of filtering the SDKs support, but I don't think they help here. For example, you can specify evaluation_contexts and return a subset, but this is a manually curated list, not automatic based on flag filters.
Activity
marandaneto commentedon Jun 17, 2026
afaik no other SDKs have that
@PostHog/team-feature-flags, does the API support filtering?
haacked commentedon Jun 17, 2026
Short answer: no, this isn't possible today, and to answer @marandaneto, the API doesn't support filtering by group type. The
groupsparameter is only an evaluation context. The/flagsresponse returns each flag's value/variant with no group-type metadata attached, so there's nothing in that payload to filter on.Worth calling out why evaluating with
groupsdoesn't already give you this: flags targeting other group types do come back asfalse(you're not passing those groups), so they're effectively neutralized. But person-based flags still evaluate against thedistinct_idand can returntrue, and your own project flags that are currently off returnfalse. So the value alone can't tell "not a project flag" apart from "a project flag that's off." Distinguishing those needs the flag'saggregation_group_type_index, which/flagsdoesn't return.To support this properly we'd need to update the
/flagsendpoint to include the group type and/or accept a group-type filter. We wouldn't want to build it as an SDK-only feature on top of local evaluation, becauseget_all_flagshas to behave the same whether or not a personal API key is configured. Implementing it only for the local-eval path would mean the same call returns different results depending on your setup, which we don't want.In the meantime, your option 2 works today. The flag definitions at
/api/projects/{id}/feature_flags/includeaggregation_group_type_indexon each flag'sfilters, so you can fetch those once and use them to filter the results ofget_all_flagsby group type yourself.There are other types of filtering the SDKs support, but I don't think they help here. For example, you can specify
evaluation_contextsand return a subset, but this is a manually curated list, not automatic based on flag filters.