> ## 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.

# LaunchDarkly change integration

> Sync LaunchDarkly feature flag and segment changes to Flashduty On-call through a LaunchDarkly webhook, 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 a LaunchDarkly organization webhook to sync feature flag and segment changes to Flashduty On-call. Each flag or segment entry in LaunchDarkly's change history becomes one Flashduty change, for example turning a flag on or off, editing targeting rules, or changing the default rule.

LaunchDarkly 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 **LaunchDarkly** and enter an integration name
  3. To assign changes to specific channels, add rules under the integration's **Routes** that match labels such as `project`, `environment`, or `flag`
  4. Click **Save** and copy the generated **Push URL**
</div>

## Configure LaunchDarkly

***

<Steps>
  <Step title="Open the Webhooks integration">
    1. Click the **gear** icon in the left sidebar to open **Organization settings**
    2. Click **Integrations**, find **Webhooks**, and click **Add new**

    You need a member role that can manage integrations, such as Admin.
  </Step>

  <Step title="Enter the push URL">
    1. **Name**: enter a recognizable name, such as `Flashduty`
    2. **URL**: paste the full push URL of the Flashduty integration
    3. **Sign this webhook**: leave it unchecked. Flashduty authenticates the delivery by the `integration_key` in the push URL
  </Step>

  <Step title="Choose what to send">
    Without a policy, LaunchDarkly sends only flag changes in the **production** environment. To send other environments or segment changes, add this policy:

    ```json theme={null}
    [
      {
        "effect": "allow",
        "actions": ["*"],
        "resources": ["proj/*:env/*:flag/*"]
      },
      {
        "effect": "allow",
        "actions": ["*"],
        "resources": ["proj/*:env/*:segment/*"]
      }
    ]
    ```

    Replace `env/*` with a specific environment (such as `env/production`) to send only that environment. Accept the terms and click **Save settings**.
  </Step>
</Steps>

LaunchDarkly has no test delivery button. After saving, make one change to any flag and the record appears in the Flashduty change list.

## What one change is

***

| LaunchDarkly object | Change key (change\_key) | Notes |
| - | - | - |
| Change history entry | The entry's `_id` | Every save of a flag or segment creates one entry, which becomes one Flashduty change; turning the same flag on and then off is two changes |

## Status mapping

***

| LaunchDarkly entry | Flashduty change status |
| - | - |
| A flag or segment change (on/off, targeting rules, default rule, variations, create, delete, archive, applying an approval request, and so on) | Done |

These deliveries are accepted without creating a change:

* Entries for other resource kinds, such as projects, environments, members, roles, webhooks, metrics, and experiments
* Entries that contain only the following actions, which do not change how a flag evaluates:
  * Creating, updating, reviewing, or deleting an approval request (once an approval request is applied, LaunchDarkly sends the entry for that step)
  * Creating, updating, or deleting scheduled changes (the entry for the scheduled change is sent when it runs)
  * Name, description, tags, maintainer, temporary flag, deprecation, custom properties, rule descriptions, code references, flag links, followers, and segment exports

## Change content

***

| Field | Content |
| - | - |
| Title | `<flag or segment name> in <environment>: <action>`, such as `Checkout redesign in production: turned on the flag`; project-wide actions (such as creating a flag) name no environment |
| Description | The change comment and LaunchDarkly's change details |
| Link | The flag or segment page in LaunchDarkly |

Labels can be used in routes and to filter the change list:

| Label | Description |
| - | - |
| `project` | Project key |
| `environment` | Environment key, such as `production`; absent for project-wide actions |
| `flag` | Flag key (flag changes) |
| `segment` | Segment key (segment changes) |
| `kind` | `flag` or `segment` |
| `action` | LaunchDarkly actions, comma-separated when there are several, such as `updateOn` or `updateRules` |
| `actor` | The name of the member who made the change, or the access token or application name for API changes |
| `audit_log_id` | Change history entry ID |

## FAQ

***

<AccordionGroup>
  <Accordion title="Why are changes from staging or segments not arriving?">
    Without a policy, LaunchDarkly sends only flag changes in the production environment. Add a policy as described in **Choose what to send**.
  </Accordion>

  <Accordion title="Does a LaunchDarkly retry record a duplicate?">
    No. When a delivery fails, LaunchDarkly retries it once with the same content, and Flashduty records it once.
  </Accordion>

  <Accordion title="Deliveries arrive out of order?">
    LaunchDarkly does not guarantee chronological delivery. Flashduty uses the entry's own time (`date`) as the change time.
  </Accordion>

  <Accordion title="Why does a delivery return InvalidParameter?">
    * `_id is missing`: the payload is incomplete. Make sure the delivery comes from a native LaunchDarkly webhook
    * `invalid date`: the time field in the payload is malformed
  </Accordion>
</AccordionGroup>