What are Featureflip webhooks?

Webhooks send an HTTP request to an endpoint you control whenever a flag or other configuration changes in Featureflip. Each request is a signed JSON description of one change: what changed, who changed it, the before and after values, and when it happened. Teams use them to trigger deploys, post changes to a chat channel, refresh caches, or feed an audit pipeline of their own. Deliveries that fail are retried and logged, and you can redeliver any of them by hand.

How do I check that a webhook came from Featureflip?

Verify its signature. Every delivery carries webhook-id, webhook-timestamp and webhook-signature headers, and the signature is an HMAC-SHA256 of the id, timestamp and raw body computed with your subscription's signing secret. Recompute it on your side and reject the request if it doesn't match. The secret is shown once, when you create the subscription or rotate it, and the webhooks guide includes working Node.js and Python examples.

What happens if my endpoint is down?

Featureflip retries the delivery on a backoff schedule. If every attempt fails, the delivery is marked failed and stays in the subscription's delivery log, where you can send it again once your endpoint is back. A subscription that keeps failing round after round switches itself off, and you re-enable it from the dashboard or the API, then redeliver whatever you still need.

Do webhook deliveries arrive in order?

Not always. Deliveries go out concurrently and at least once, so a retried event can land after a later one, and the same event can arrive twice. Deduplicate on the webhook-id header, which stays the same across retries, and order changes by the occurredAt field in the payload. Many receivers skip ordering entirely and treat each delivery as a cue to re-read current state through the API.

How many webhooks can I create?

It depends on the plan. Free includes 1 webhook endpoint. Team includes 3 webhook endpoints. Pro includes 3 webhook endpoints. Business includes unlimited webhook endpoints, and Enterprise is unlimited too. Only organization admins can view or manage subscriptions.

Are webhooks how SDKs receive flag changes?

No. SDKs keep their own streaming connection to Featureflip and pick up changes within seconds with nothing to configure. Webhooks are for the rest of your systems: the CI pipeline, the chat channel, the data warehouse, anything that should hear about a change without holding an SDK.

Product feature

Feature flag webhooks

Tell your deploy pipeline, your chat channel or your cache the moment a flag changes. One signed request per change, retried until your endpoint answers.

Last updated: September 30, 2026

Featureflip webhooks send a signed HTTP request to your endpoint whenever a flag or its configuration changes. Toggles, targeting rules, variations, segments, environments, projects, SDK keys and API tokens all produce events, and each subscription picks the event types, projects and environments it wants. Every delivery carries an HMAC signature, failed deliveries are retried and logged, and you can redeliver any of them. Subscriptions are managed from the dashboard, the Management API, the MCP server or Terraform, and every plan includes at least one.

Get started free Read the webhooks guide

How Featureflip webhooks work

Six pieces that let the rest of your stack hear about a flag change without asking the API every minute.

Every change, sent as it happens

Toggle a flag, edit a targeting rule or rotate an SDK key, and Featureflip sends your endpoint one HTTP request describing what moved. Kick off a deploy from it, post it to a chat channel, drop a cache entry, or feed your own audit store. Nothing has to poll the API on a timer.

Signed with a secret only you hold

Each delivery carries an HMAC signature computed with your subscription's signing secret. Your handler recomputes it over the raw body and throws away anything that doesn't match. The webhooks guide has verification code for Node.js and Python you can paste in.

Secret rotation without a gap

Add a new signing secret and every delivery is signed with both the old and the new one until you retire the old one. Your endpoint moves over whenever it is ready, and Featureflip refuses to retire the last active secret, so a subscription is never left unsigned.

Only the events you asked for

Pick event types, or take all of them, and narrow a subscription to particular projects and environments. A toggle in staging never has to wake up the production deploy pipeline.

Retries, a log and redelivery

A delivery your endpoint fails is retried on a backoff schedule. Each subscription keeps a log of its deliveries with status, attempt count and the last error, so you can redeliver any one by hand after a fix, or send a test event before you rely on a new endpoint.

Managed wherever you manage flags

Create subscriptions in Organization Settings, over the /api/v1 Management API, from an AI agent through the MCP server, or as a featureflip_webhook resource in Terraform. That last route puts a new receiver through the same pull request as the flags it listens to.

The webhooks guide covers the full event catalog, signature verification, retries, redelivery and secret rotation, with request and response shapes for every endpoint.

What a delivery looks like

One JSON object per change. Here is the body Featureflip sends when someone turns new-checkout on in production, trimmed to the fields most receivers read:

{
  "type": "flag.toggled",
  "occurredAt": "2026-09-23T14:32:07.412Z",
  "environmentId": "0199f2aa-3333-7222-8333-444455556666",
  "actor": { "email": "jane@example.com", "name": "Jane Doe" },
  "entity": { "type": "FeatureFlag", "id": "0199f2aa-5555-7222-8333-444455556666" },
  "changes": [
    { "property": "IsEnabled", "from": "false", "to": "true" }
  ],
  "description": "Toggled \"new-checkout\" on in Production"
}

entity names the flag, segment or project the change belongs to, the thing you'd look up through the REST API. A change to something beneath it, like a targeting rule, adds a child naming that object.
changes lists each property that moved, with its old and new value, so a chat message can say exactly what happened without a second call.
occurredAt is when the change was made, and it is what to order by. Deliveries can arrive out of order and more than once, and the webhook-id header is stable across retries for deduplication.

The same change also lands in the audit log, so a webhook is a copy of the record you already keep, sent somewhere you choose.

Four places to manage them, on every plan

Most teams add their first subscription from the Webhooks card in Organization Settings. Scripts use the /api/v1 webhook endpoints, which accept an Idempotency-Key on create like the rest of the public API. Agents in Claude Code, Cursor or Copilot reach the same subscriptions through four tools on the MCP server, including one that sends a test event. And teams that keep flags in HCL declare a featureflip_webhook resource with the Terraform provider, where rotating a secret is a featureflip_webhook_secret resource.

Every plan includes webhooks. The number of endpoints grows with the plan:

Free: 1 webhook endpoint
Team: 3 webhook endpoints
Pro: 3 webhook endpoints
Business: unlimited webhook endpoints
Enterprise: unlimited webhook endpoints

Every other limit, and what happens to extra endpoints when a plan changes, is on the plans and limits page.

Frequently asked questions

What are Featureflip webhooks?: Webhooks send an HTTP request to an endpoint you control whenever a flag or other configuration changes in Featureflip. Each request is a signed JSON description of one change: what changed, who changed it, the before and after values, and when it happened. Teams use them to trigger deploys, post changes to a chat channel, refresh caches, or feed an audit pipeline of their own. Deliveries that fail are retried and logged, and you can redeliver any of them by hand.
How do I check that a webhook came from Featureflip?: Verify its signature. Every delivery carries webhook-id, webhook-timestamp and webhook-signature headers, and the signature is an HMAC-SHA256 of the id, timestamp and raw body computed with your subscription's signing secret. Recompute it on your side and reject the request if it doesn't match. The secret is shown once, when you create the subscription or rotate it, and the webhooks guide includes working Node.js and Python examples.
What happens if my endpoint is down?: Featureflip retries the delivery on a backoff schedule. If every attempt fails, the delivery is marked failed and stays in the subscription's delivery log, where you can send it again once your endpoint is back. A subscription that keeps failing round after round switches itself off, and you re-enable it from the dashboard or the API, then redeliver whatever you still need.
Do webhook deliveries arrive in order?: Not always. Deliveries go out concurrently and at least once, so a retried event can land after a later one, and the same event can arrive twice. Deduplicate on the webhook-id header, which stays the same across retries, and order changes by the occurredAt field in the payload. Many receivers skip ordering entirely and treat each delivery as a cue to re-read current state through the API.
How many webhooks can I create?: It depends on the plan. Free includes 1 webhook endpoint. Team includes 3 webhook endpoints. Pro includes 3 webhook endpoints. Business includes unlimited webhook endpoints, and Enterprise is unlimited too. Only organization admins can view or manage subscriptions.
Are webhooks how SDKs receive flag changes?: No. SDKs keep their own streaming connection to Featureflip and pick up changes within seconds with nothing to configure. Webhooks are for the rest of your systems: the CI pipeline, the chat channel, the data warehouse, anything that should hear about a change without holding an SDK.

Wire your first webhook in a few minutes

The Free plan includes a webhook endpoint, the Management API and the MCP server, and it doesn't expire. Paid plans raise the endpoint count with nothing metered.

Get started free See pricing