Webhooks integrations

Global concept

Webhooks enable custom integration with your own tools by having our platform call your web services when a specific Flagship event occurs.

How to create a webhook?

You can create a webhook subscription in the Flagship platform in the Settings -> Platform Integration section

1255

A webhook requires 3 fields to be created:

• The event type: this field specifies the Flagship events you want your webhook to listen to. see the event types

• A hook URL: this field specifies the URL that Flagship will call when the event occurs

• A description: this field is a plain text field to explain what the webhook is for, for organizational purposes.

When an event is triggered, Flaghip will send an HTTP POST request to the specified hook URL, with a JSON body containing common fields and fields related to the event type.

Common fields in the Webhook request body

Those fields will be sent for all webhook events to the hook URL:

• event: the event type that occured

• user_id: the ID of the user that triggered the event

• user_email: the email of the user that triggered the event

• user_role: the role of the user that triggered the event

• date: the date (ISO-8601 - eg "2005-08-15T15:52:01+00:00") the event occured

Event types

There are currently 5 event types handled by the Flagship webhook system:

Feature events

Feature events are triggered when something happens to a feature. All the feature events will contain the common fields and these additional fields:

• account_id: the account ID of the campaign that has changed state

• account_name: the account name of the campaign that has changed state

• environment_id: the environment ID of the campaign that has changed state

• campaign_id: the ID of the feature that has changed state

• campaign_name: the name of the feature that has changed state

• campaign_type: the type of the feature that has changed state (ab, toggle, perso or deployment)

• campaign_status: will contain the new state of the campaign (active, paused or interrupted)

Feature.active

This event will trigger your webhook when a feature is turned ON

Feature.paused

This event will trigger your webhook when a feature is turned OFF or interrupted automatically in the case of a rollback KPI in a deployment use case.

Feature.state

This event will trigger your webhook when a feature state change (eg from Live to Paused for instance)

Flag reference events

Flag reference events are triggered when something changes to your flag reference integration (with a git solution provider). See Codebase Analyzer for more details.

All the Flag reference events will contain the common fields and these additional fields:

• account_id: the account ID of the flag reference that triggered the event

• account_name: the account name of the flag reference that triggered the event

• environment_id: the environment ID of the flag reference that triggered the event

• environment_name: the environment name of the flag reference that triggered the event

• flag_key: the key of the flag reference that triggered the event

Flag.new

This event is triggered when a new Flag reference is detected in your codebase after a commit is pushed for instance.

Flag.deleted

This event is triggered when a specific Flag reference is not found anymore in your codebase after a commit is pushed for instance.

Environment.sync

This event is triggered when modifications are made on the platform. Decision API cache is reloaded and bucketing file is re-generated.

With this event type, you can configure headers/payload additional parameters and also call gihtub.com, gitlab.com and other CI/CD APIs. You can find how to it here.

Any feedback? We would be really happy to have a quick chat!