In Flashduty On-call
- In the Flashduty console, go to Integration Center → Change Events
- Select GrowthBook and enter an integration name
- To send changes to a specific channel, add rules in the integration’s Route on labels such as
feature_id - Click Save and copy the generated Push URL
Configure in GrowthBook
1
Create an Event Webhook
- Log in to GrowthBook as an admin and go to Settings → Webhooks
- Click New Event Webhook and enter a Webhook Name (required)
2
Enter the push URL
- Payload Type: choose JSON. Raw (Legacy) is the old format and does not send revision events
- Method: keep
POST - Endpoint URL: paste the full push URL of the Flashduty integration
- Headers: leave empty. Flashduty authenticates with the
integration_keyin the push URL. GrowthBook adds a signature in theX-GrowthBook-Signatureheader; Flashduty does not verify it
3
Select events and scope
- Events: select the events below; Flashduty ignores other events
feature.revision.reviewRequested,feature.revision.changesRequested,feature.revision.approvedfeature.revision.published,feature.revision.revertedfeature.revision.discarded,feature.revision.publishFailed
- Environments, Projects, Tags: leave empty for all, or limit to the scope you care about, such as production
- Click Create
feature.revision.* wildcard: Flashduty rejects revision events that GrowthBook adds later (see the FAQ below). Feature-level events such as feature.updated are ignored even when subscribed.feature.revision.* events. Before saving, you can click Test Connection in the create dialog: it sends a body without an event field, and Flashduty returns 200 and records no change. A saved webhook has no Test button in current versions. Then publish a revision on any feature to see it in the Flashduty change list.
How changes are merged
A feature ID cannot be changed after creation, and revision versions increase within a feature. If you delete a feature and re-create it with the same ID, versions restart. A new revision then merges into the old feature’s change with the same version number.
Status mapping
When a feature has no approval flow, publishing sends only
published, so the change is Done from the start.
These deliveries return success and record no change:
- Revision events that do not move the revision forward:
created,updated,rebased,commented,reopened,recalled,reviewRetracted,publishScheduleChanged - Feature-level events such as
feature.created,feature.updatedandfeature.deleted, and events of other resources such as safe rollouts, ramp schedules, experiments and saved groups - The test request sent by Test Connection, and any delivery without an
event
feature.revision.* event that GrowthBook adds later returns InvalidParameter until we add it to the table above, and Flashduty records no change.
Change content
Use labels for routing and for filtering the change list:
state, actor and event_type are updated by every event, so do not route on them; use feature_id, which every event carries. Project and environment scope differs between events, so Flashduty does not record it.
FAQ
Does a GrowthBook retry create duplicates?
Does a GrowthBook retry create duplicates?
No. GrowthBook tries a delivery up to 3 times when the endpoint does not return 200. Flashduty uses the event’s own time (
created) as the change time, so Flashduty records a repeated delivery once, and a late older state cannot overwrite a finished change.Why is there no review record for a revision I published?
Why is there no review record for a revision I published?
Only features with an approval flow produce
reviewRequested and approved. A revision published directly has a single published event.The push returns an InvalidParameter error?
The push returns an InvalidParameter error?
… is missingorinvalid …: the payload is incomplete or a field is malformed. Confirm it comes from a GrowthBook webhookunsupported …orunknown …: Flashduty does not support this revision event yet. Contact us- Select only the events listed above, and make sure Payload Type is JSON (a non-JSON body returns the same error)