Product feature

Feature flag REST API

Everything the dashboard does, over HTTP. Create flags from CI, toggle them from a deploy script, and wire flags into your own internal tools.

Last updated:

The Featureflip Management API puts your whole flag configuration behind a REST interface at api.featureflip.io: projects, environments, flags, variations, toggles, targeting rules, segments, and SDK keys. Requests authenticate with a bearer token, creates are idempotent so retries are safe, every response carries rate-limit headers, and every change lands in the audit log and streams live to your SDKs. It is included on every plan.

Get started freeRead the API docs

Built for automation, not just completeness

An API a script can trust: predictable addressing, safe retries, visible limits, and errors that say what went wrong and where to read about it.

The whole surface, not a subset

Everything you configure in the dashboard is available over REST: projects, environments, feature flags and their variations, per-environment configuration, on/off toggles, targeting rules, reusable segments, and SDK keys. If the dashboard can change it, a script can too.

Two kinds of token

A Personal Access Token acts as you, with your role in each organization, which suits one-off scripts and local tooling. A Service Token is a machine identity scoped to one organization with an explicit role, and can be confined to an allowlist of projects, so your CI pipeline touches only what it should.

Safe to retry

Creates accept an Idempotency-Key header. Retry the same request after a timeout and you get the original result back instead of a duplicate flag; a concurrent retry returns a 409 rather than racing. Automation can be blunt about network failures without leaving debris behind.

Rate limits you can see

Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, not just the ones that get throttled. A well-behaved script can pace itself before hitting 429, and when it does hit one, the response includes a Retry-After telling it exactly how long to back off.

Errors built for scripts

Every error uses one frozen JSON envelope with a stable machine-readable code, a human-readable message, and a docs_url linking to the page for that exact code. Validation failures list the offending fields; an unknown key answers with a did_you_mean suggestion.

Addressed by the keys you already use

Resources are addressed by the same keys and slugs you see in the dashboard, so a script reads like the thing it does: /orgs/acme/projects/checkout/flags/new-checkout. Lists are cursor-paginated, and every response includes an _actions map of what your token may do next.

Pagination, the error envelope, rate limiting, and idempotency are specified in the API conventions, and every endpoint is in the OpenAPI reference.

A flag, from nothing to live, in two requests

Resources are addressed by the keys you already use in the dashboard, so the calls read like what they do. Create a flag, then turn it on in one environment:

# create the flag (Idempotency-Key makes a retry safe)
curl -X POST https://api.featureflip.io/api/v1/orgs/acme/projects/checkout/flags \
  -H "Authorization: Bearer $FEATUREFLIP_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 6f9619ff-8b86-d011-b42d-00cf4fc964ff" \
  -d '{ "key": "new-checkout", "name": "New checkout", "type": "Boolean" }'

# enable it in production
curl -X POST https://api.featureflip.io/api/v1/orgs/acme/projects/checkout/flags/new-checkout/environments/production/toggle \
  -H "Authorization: Bearer $FEATUREFLIP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": true }'

The toggle streams to every connected SDK over SSE, the same path a dashboard change takes. The quickstart walks the full sequence from token to targeting rule, and the blog covers managing feature flags programmatically end to end, from the write-plane and read-plane split to the automation patterns it unlocks.

Seeding a flag from CI, step by step

The most common automation: the pipeline creates the flag before the code that references it ever deploys, so the reference can never dangle.

  1. 1

    Create a token

    Generate a Personal Access Token under Settings, or a Service Token scoped to one organization and, optionally, specific projects for shared automation. Send it as a bearer token on every request.

  2. 2

    Create the flag

    POST the flag with its key, name, and type. Send an Idempotency-Key so a retried request cannot create a duplicate. The response includes the generated variations and an _actions map of what you can do next.

  3. 3

    Enable it where you want it

    A new flag starts off in every environment. Toggle it on in staging from the same script, or add a targeting rule so only your beta segment sees it in production.

  4. 4

    Your SDKs pick it up live

    The change streams to every connected SDK over SSE within moments, the same as a dashboard edit. And like a dashboard edit, it lands in the audit log with the actor attached.

The same pattern covers the other direction: when a rollout completes, a cleanup job can archive the flag through the API, keeping flag debt from accumulating.

One control plane, two doors

The API and the dashboard drive the same configuration, so everything composes the way you would expect:

  • Environments are first-class in every path. A toggle, a rollout percentage, or a rule change is scoped to one environment, so a script can promote a flag from staging to production the same way a person would.
  • Targeting is scriptable end to end. Rules, condition groups, percentage rollouts, and reusable segments can all be created, reordered, and replaced atomically over the API.
  • Every API change is in the audit log. Writes made with a token are recorded with before and after values like any dashboard change, so automation stays as reviewable as people.
  • Management and evaluation stay separate. The Management API configures flags; your SDKs and the Evaluation API serve them. Heavy automation can never sit in the request path of a flag check.

There is a door for AI agents, too. The MCP server (@featureflip/mcp) exposes this same Management API as tools for Claude Code, Cursor, and other AI coding assistants, so an agent can create a flag, ramp a rollout, or clean up stale ones from inside the editor. The blog walks through managing feature flags from your AI assistant end to end.

Frequently asked questions

Does Featureflip have a REST API for managing feature flags?
Yes. The Management API at api.featureflip.io exposes everything the dashboard can do under /api/v1: create, update, archive, and delete flags, toggle them per environment, manage variations, targeting rules, segments, environments, projects, and SDK keys. It is authenticated with bearer tokens, documented with a full OpenAPI reference, and separate from the Evaluation API that serves flags to your SDKs at runtime.
Can I toggle a feature flag from a script or CI pipeline?
Yes. A single POST to the flag's toggle endpoint with {"enabled": true} turns it on in one environment, and the change streams to your connected SDKs over SSE just like a dashboard toggle. Teams use this to seed flags from CI before the code that references them deploys, to flip a flag as a deployment step, and to archive flags automatically once a rollout completes.
How does authentication work for the Featureflip API?
Every request sends a bearer token in the Authorization header. There are two kinds: a Personal Access Token acts as you with your role in each organization and is created under Settings, while a Service Token is a machine identity scoped to a single organization with an explicit role, optionally confined to an allowlist of projects. Service Tokens suit CI and shared automation because they are not tied to a person and keep working after team changes.
Is the API safe to retry after a timeout?
Yes. Requests that create a resource accept an Idempotency-Key header with a unique UUID per logical create. If the same token retries with the same key, the original result is replayed instead of creating a duplicate; if a second request with the same key arrives while the first is still in flight, it returns a 409 so the two cannot race. Updates and toggles set an explicit state, so repeating them is naturally harmless.
How are rate limits communicated?
Every response, not only throttled ones, carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, so a script can watch its budget and pace itself. If the limit is exceeded, the API returns 429 with a stable rate_limited error code, a retry_after field, and a Retry-After header telling the client exactly how many seconds to wait before retrying.
Is API access included on every plan?
Yes. The Management API is available on every plan, including the free Solo tier, and is not an enterprise add-on. Your plan's resource limits, such as how many flags a project can hold, apply the same through the API as through the dashboard, and flat pricing means API calls themselves are not metered or billed.

Put your flags on autopilot

The Management API is included on every plan, from the free Solo tier up, on flat pricing with no metering on API calls.

Get started freeSee pricing

Related

Management API (docs)

Base URL, authentication, and what you can manage, with links to every endpoint.

API quickstart (docs)

From token to a live, targeted flag in a few requests.

SDKs (feature)

The serving side: 13 SDKs that evaluate what the API configures, locally and in sub-milliseconds.

Audit log (feature)

Every change made through the API is recorded with before and after values, like any dashboard change.