Feature flags API

There are two APIs for feature flags, and they answer different questions. The /flags endpoint evaluates flags for a user at runtime – it's what the SDKs call under the hood, and it's what you use if there's no SDK for your platform. The feature flags API manages the flag definitions themselves: create, list, update, and delete flags from your own tooling or CI.

Use the API when you want flags in a place PostHog doesn't ship an SDK for, or when flag management should be part of a pipeline rather than a person clicking through the app.

What you can do here

Evaluate flags with /flags, using your public project API key and a distinct_id. It returns each flag's value for that user, plus any payloads. See the API installation guide for the request shape.

Manage flag definitions with the feature flags API, using a personal API key scoped to feature_flag:read or feature_flag:write. This covers creating and updating flags, release conditions, variants, and scheduled changes.

Check impact before you roll out – the same endpoints back the blast radius, evaluation reasons, and flag status checks you see in the web app, so CI can gate a rollout on them.

For high-volume server-side evaluation, don't call /flags per request. Use local evaluation instead: your server pulls the flag definitions once and resolves values in-process.

Related

• Create and roll out flags in the web app.
• Do the same thing conversationally over MCP.
• Read the full PostHog API reference.