// wiki / realtime-updates

Realtime updates — three transports

Polling, signed webhooks, and streaming — same event contract on all three.

Flag-change notifications use a shared JSON envelope across the supported delivery channels. Choose the channels that fit your application.

1 · HTTP polling
Always on

Your client calls POST /flags/<name> with a Management Key whenever it needs an answer. This is a straightforward request-response integration; update frequency depends on the client's polling schedule.

2 · Webhooks
Server-to-server push

Configured webhooks receive flag-change payloads. When signing is enabled, verify the HMAC-SHA256 value in X-Webhook-Signature against the raw request body. Delivery history and replay controls are available in the dashboard.

Set up a webhook →
3 · Streaming
Persistent client connection

A client can open a streaming connection at /hubs/flags and subscribe to flag-change notifications. Configure reconnect and state-refresh behavior in the client. See the SignalR streaming guide for .NET connection details.

Streaming groups & tag scope

Each streaming connection is scoped by its Streaming key to one flag and environment. To follow several flags, open one connection per key, and refresh current state after reconnecting or detecting a delivery gap.

Streaming deployment and capacity depend on the configured backplane. Review your environment's configuration when planning for higher traffic.

Cache invalidation & notification matrix

Every change type below follows the same pattern: the cache clears first, then a notification goes out on whichever transports you've configured, then anything that depends on the changed flag gets re-evaluated. Use this as a reference for what to expect after a given change.

Change scenarioCache invalidatedPush / notify retriggeredDependent flags re-evaluated
Flag enabled or disabledYesYes, affected environmentYes, transitively
Targeting rules changedYesYesYes
Rollout percentage changedYesYesYes
Default variant changedYesYesYes
Variants added, removed, or editedYes, all environmentsYes, all configured environmentsYes
Enrollment cutoff changedYesYesYes
Environment configuration createdYesYesYes
Environment configuration removedYesYesYes
Configuration promotedYes, target environmentYes, target environmentYes
Configuration unpromotedYesYesYes
Configuration reverted from audit historyYesYesYes
Dependency list changedYes, all environmentsYes, all configured environmentsYes
Parent metadata changedYesYes, all configured environmentsYes
Flag archivedYes, all environmentsYes, all configured environmentsYes
Flag restored / unarchivedYes, all environmentsYes, all configured environmentsYes
Flag renamedOld and new cache scopes clearedOld and new flag notificationYes, using updated graph
Flag deletedYesYesOnly after dependency safety checks pass
Bulk enable / disableYesYesYes
Bulk archiveYesYesYes
Approved enable / disable / updateYesYes, correct environmentYes
Approved promotion / unpromotionYesYes, correct target environmentYes
Automation enable / disableYesYesYes
Automation rollout changeYesYesYes
Automation targeting changeYesYesYes
Automation promotionYesYesYes
Automation expiration / archiveYesYesYes
Scheduled lifecycle transitionsYesYesYes
Referenced segment changed or deletedSegment cache clearedYes, for every referencing flagYes
Kill switch changedEntire organization cache clearedYes, every flag / environmentYes
Management API mutationsSame rules as the dashboardYesYes
Important behavior
  • Push/notify delivery only occurs when streaming is enabled.
  • Direct and transitive dependents are included — changing a parent retriggers both child and grandchild flags.
  • Metadata-wide notifications publish to every configured environment group.
  • Environment push/notify groups are normalized case-insensitively.
  • Approved promotions publish using the actual target environment.
Cache-only operations

A manual cache purge clears selected backend caches but does not emit a configuration-change notification, since no configuration actually changed.