> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Unleash change integration

> Sync Unleash feature flag changes to Flashduty On-call through an Unleash webhook integration, as change events you can correlate with alerts and incidents.

<Tip>**Plan requirement**: This feature requires an On-call Standard or higher subscription. [Learn more](https://flashcat.cloud/flashduty/price/)</Tip>

Use an Unleash webhook integration to sync feature flag changes to Flashduty On-call. Each Unleash event becomes one Flashduty change, for example enabling or disabling a flag in an environment, adding or editing a strategy, changing variants, or archiving a flag.

Unleash sends changes that have already taken effect, so each change is recorded as **Done** directly.

<div className="hide">
  ## In Flashduty On-call

  ***

  1. In the Flashduty console, go to **Integration Center → Change Events**
  2. Select **Unleash** and enter an integration name
  3. To send changes to a specific channel, add rules in the integration's **Route** on labels such as `project`, `environment` and `flag`
  4. Click **Save** and copy the generated **push URL**
</div>

## Configure in Unleash

***

<Steps>
  <Step title="Create a webhook integration">
    1. Open the Unleash admin UI and go to **Integrations**
    2. On the **Webhook** card, click **New integration**

    You need permission to manage integrations.
  </Step>

  <Step title="Enter the push URL">
    1. **Webhook URL**: paste the full push URL from the Flashduty integration
    2. **Content-Type**: keep the default `application/json`
    3. **Authorization** and **Extra HTTP Headers**: leave empty; Flashduty authenticates with the `integration_key` in the push URL
    4. **Body template**: leave empty. With no template Unleash sends the full event JSON, which is the format Flashduty parses
  </Step>

  <Step title="Select events and scope">
    1. **Events**: select the events below; other events are ignored
       * `feature-created`, `feature-updated`, `feature-archived`, `feature-revived`
       * `feature-environment-enabled`, `feature-environment-disabled`
       * `feature-strategy-add`, `feature-strategy-update`, `feature-strategy-remove`
       * `feature-variants-updated`
    2. **Projects** and **Environments**: leave empty for all, or select only the scope you care about, such as production
    3. Click **Save**
  </Step>
</Steps>

Unleash has no test-delivery button. After saving, change any flag (for example enable an environment) and the record appears in the Flashduty change list.

## What one change is

***

| Unleash object | Change key (`change_key`) | Notes |
| - | - | - |
| Event | The event's `id` | Each action produces one event, which is one Flashduty change; enabling a flag and disabling it again are two changes |

Event `id` increments within one Unleash instance. Create one integration per Unleash instance: if several instances share an integration, events with the same `id` are treated as the same change.

## Status mapping

***

| Unleash event | Flashduty change status |
| - | - |
| `feature-created`, `feature-updated`, `feature-archived`, `feature-revived`, `feature-environment-enabled`, `feature-environment-disabled`, `feature-strategy-add`, `feature-strategy-update`, `feature-strategy-remove`, `feature-variants-updated` | Done |

These deliveries return success but create no change:

* Change request events such as `change-request-created`, `change-request-approved` and `change-request-applied`. When a change request is applied, Unleash sends one of the events in the table above for each flag change in it, and those are recorded
* Events that do not alter how a flag evaluates: tags, stale markers, description and type, project moves
* Events about other resources (projects, environments, users, segments) and deliveries without a `type`

## Change content

***

| Field | Content |
| - | - |
| Title | `<flag name> in <environment>: <action>`, for example `new-feature in production: enabled`; events with no environment (such as creating a flag) omit it |
| Description | Empty |
| Link | Empty. Unleash events carry no page URL |

Labels for routing and for filtering the change list:

| Label | Meaning |
| - | - |
| `project` | Project ID |
| `environment` | Environment name, such as `production`; absent for events with no environment |
| `flag` | Flag name |
| `strategy` | Strategy name, such as `flexibleRollout` (strategy events only) |
| `actor` | The actor, set only when it is an API token or service account; a user's email is never written to a label |
| `event_type` | Unleash event type, such as `feature-environment-enabled` |
| `event_id` | Unleash event ID |

## FAQ

***

<AccordionGroup>
  <Accordion title="Does an Unleash retry record a duplicate?">
    No. When a delivery fails (a 50x or a network error) Unleash retries once with the same content, and Flashduty records it once. Unleash does not guarantee delivery order; Flashduty uses the event's own time (`createdAt`) as the change time.
  </Accordion>

  <Accordion title="Why are change request notifications not recorded?">
    A change request does not alter production behavior until it is applied. On apply, Unleash sends the matching `feature-*` event for each flag change in it, and Flashduty records those events.
  </Accordion>

  <Accordion title="The push returns an InvalidParameter error?">
    * `id is missing`, `featureName is missing`: the body is incomplete. Make sure **Body template** is empty
    * `invalid createdAt`: the event time is not in a valid format
    * Body is not JSON: make sure **Content-Type** is `application/json` and that any **Body template** renders valid JSON
  </Accordion>
</AccordionGroup>