LaunchDarkly

Fetch a list of all access tokens.

Create a new access token.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/AccessTokenPost"
      },
      "example": {
        "role": "reader"
      }
    }
  },
  "required": true
}

Delete an access token by ID.

Get a single access token by ID.

Update an access token's settings. Updating an access token uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/role",
          "value": "writer"
        }
      ]
    }
  },
  "required": true
}

Reset an access token's secret key with an optional expiry time for the old key.

Return a list of account members. By default, this returns the first 20 members. Page through this list with the `limit` parameter and by following the `first`, `prev`, `next`, and `last` links in the returned `_links` field. These links are not present if the pages they refer to don't exist. For example, the `first` and `prev` links will be missing from the response on the first page. ### Filtering members LaunchDarkly supports the following fields for filters: - `query` is a string that matches against the members' emails and names. It is not case sensitive. - `role` is a `|` separated list of roles and custom roles. It filters the list to members who have any of the roles in the list. For the purposes of this filtering, `Owner` counts as `Admin`. - `team` is a string that matches against the key of the teams the members belong to. It is not case sensitive. - `noteam` is a boolean that filters the list of members who are not on a team if true and members on a team if false. - `lastSeen` is a JSON object in one of the following formats: - `{"never": true}` - Members that have never been active, such as those who have not accepted their invitation to LaunchDarkly, or have not logged in after being provisioned via SCIM. - `{"noData": true}` - Members that have not been active since LaunchDarkly began recording last seen timestamps. - `{"before": 1608672063611}` - Members that have not been active since the provided value, which should be a timestamp in Unix epoch milliseconds. - `accessCheck` is a string that represents a specific action on a specific resource and is in the format `<ActionSpecifier>:<ResourceSpecifier>`. It filters the list to members who have the ability to perform that action on that resource. Note: `accessCheck` is only supported in API version `20220603` and earlier. To learn more, read [Versioning](https://apidocs.launchdarkly.com/#section/Overview/Versioning). - For example, the filter `accessCheck:createApprovalRequest:proj/default:env/test:flag/alternate-page` matches members with the ability to create an approval request for the `alternate-page` flag in the `test` environment of the `default` project. - Wildcard and tag filters are not supported when filtering for access. For example, the filter `query:abc,role:admin|customrole` matches members with the string `abc` in their email or name, ignoring case, who also are either an `Owner` or `Admin` or have the custom role `customrole`. ### Sorting members LaunchDarkly supports two fields for sorting: `displayName` and `lastSeen`: - `displayName` sorts by first + last name, using the member's email if no name is set. - `lastSeen` sorts by the `_lastSeen` property. LaunchDarkly considers members that have never been seen or have no data the oldest.

Invite one or more new members to join an account. Each member is sent an invitation. Members with "admin" or "owner" roles may create new members, as well as anyone with a "createMember" permission for "member/\*". If a member cannot be invited, the entire request is rejected and no members are invited from that request. Each member _must_ have an `email` field and either a `role` or a `customRoles` field. If any of the fields are not populated correctly, the request is rejected with the reason specified in the "message" field of the response. Requests to create account members will not work if SCIM is enabled for the account. _No more than 50 members may be created per request._ A request may also fail because of conflicts with existing members. These conflicts are reported using the additional `code` and `invalid_emails` response fields with the following possible values for `code`: - **email_already_exists_in_account**: A member with this email address already exists in this account. - **email_taken_in_different_account**: A member with this email address exists in another account. - **duplicate_email**s: This request contains two or more members with the same email address. A request that fails for one of the above reasons returns an HTTP response code of 400 (Bad Request).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/NewMemberFormListPost"
      }
    }
  },
  "required": true
}

Delete a single account member by ID. Requests to delete account members will not work if SCIM is enabled for the account.

Get a single account member by member ID. `me` is a reserved value for the `id` parameter that returns the caller's member information.

Update a single account member. Updating a member uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com). To update fields in the account member object that are arrays, set the `path` to the name of the field and then append `/<array index>`. Use `/0` to add to the beginning of the array. Use `/-` to add to the end of the array. For example, to add a new custom role to a member, use the following request body: ``` [ { "op": "add", "path": "/customRoles/0", "value": "some-role-id" } ] ``` You can update only an account member's role or custom role using a JSON patch. Members can update their own names and email addresses though the LaunchDarkly UI. When SAML SSO or SCIM is enabled for the account, account members are managed in the Identity Provider (IdP). Requests to update account members will succeed, but the IdP will override the update shortly afterwards.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "add",
          "path": "/role",
          "value": "writer"
        }
      ]
    }
  },
  "required": true
}

Add one member to one or more teams.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/MemberTeamsPostInput"
      }
    }
  },
  "required": true
}

> ### Full use of this API resource is an Enterprise feature > > The ability to perform a partial update to multiple members is available to customers on an Enterprise plan. If you are on a Pro plan, you can update members individually. To learn more, [read about our pricing](https://launchdarkly.com/pricing/). To upgrade your plan, [contact Sales](https://launchdarkly.com/contact-sales/). Perform a partial update to multiple members. Updating members uses the semantic patch format. To make a semantic patch request, you must append `domain-model=launchdarkly.semanticpatch` to your `Content-Type` header. To learn more, read [Updates using semantic patch](https://apidocs.launchdarkly.com). ### Instructions Semantic patch requests support the following `kind` instructions for updating members. <details> <summary>Click to expand instructions for <strong>updating members</strong></summary> #### replaceMembersRoles Replaces the roles of the specified members. This also removes all custom roles assigned to the specified members. ##### Parameters - `value`: The new role. Must be a valid built-in role. To learn more about built-in roles, read [LaunchDarkly's built-in roles](https://docs.launchdarkly.com/home/members/built-in-roles). - `memberIDs`: List of member IDs. Here's an example: ```json { "instructions": [{ "kind": "replaceMemberRoles", "value": "reader", "memberIDs": [ "1234a56b7c89d012345e678f", "507f1f77bcf86cd799439011" ] }] } ``` #### replaceAllMembersRoles Replaces the roles of all members. This also removes all custom roles assigned to the specified members. Members that match any of the filters are **excluded** from the update. ##### Parameters - `value`: The new role. Must be a valid built-in role. To learn more about built-in roles, read [LaunchDarkly's built-in roles](https://docs.launchdarkly.com/home/members/built-in-roles). - `filterLastSeen`: (Optional) A JSON object with one of the following formats: - `{"never": true}` - Members that have never been active, such as those who have not accepted their invitation to LaunchDarkly, or have not logged in after being provisioned via SCIM. - `{"noData": true}` - Members that have not been active since LaunchDarkly began recording last seen timestamps. - `{"before": 1608672063611}` - Members that have not been active since the provided value, which should be a timestamp in Unix epoch milliseconds. - `filterQuery`: (Optional) A string that matches against the members' emails and names. It is not case sensitive. - `filterRoles`: (Optional) A `|` separated list of roles and custom roles. For the purposes of this filtering, `Owner` counts as `Admin`. - `filterTeamKey`: (Optional) A string that matches against the key of the team the members belong to. It is not case sensitive. - `ignoredMemberIDs`: (Optional) A list of member IDs. Here's an example: ```json { "instructions": [{ "kind": "replaceAllMembersRoles", "value": "reader", "filterLastSeen": { "never": true } }] } ``` #### replaceMembersCustomRoles Replaces the custom roles of the specified members. ##### Parameters - `values`: List of new custom roles. Must be a valid custom role key or ID. - `memberIDs`: List of member IDs. Here's an example: ```json { "instructions": [{ "kind": "replaceMembersCustomRoles", "values": [ "example-custom-role" ], "memberIDs": [ "1234a56b7c89d012345e678f", "507f1f77bcf86cd799439011" ] }] } ``` #### replaceAllMembersCustomRoles Replaces the custom roles of all members. Members that match any of the filters are **excluded** from the update. ##### Parameters - `values`: List of new roles. Must be a valid custom role key or ID. - `filterLastSeen`: (Optional) A JSON object with one of the following formats: - `{"never": true}` - Members that have never been active, such as those who have not accepted their invitation to LaunchDarkly, or have not logged in after being provisioned via SCIM. - `{"noData": true}` - Members that have not been active since LaunchDarkly began recording last seen timestamps. - `{"before": 1608672063611}` - Members that have not been active since the provided value, which should be a timestamp in Unix epoch milliseconds. - `filterQuery`: (Optional) A string that matches against the members' emails and names. It is not case sensitive. - `filterRoles`: (Optional) A `|` separated list of roles and custom roles. For the purposes of this filtering, `Owner` counts as `Admin`. - `filterTeamKey`: (Optional) A string that matches against the key of the team the members belong to. It is not case sensitive. - `ignoredMemberIDs`: (Optional) A list of member IDs. Here's an example: ```json { "instructions": [{ "kind": "replaceAllMembersCustomRoles", "values": [ "example-custom-role" ], "filterLastSeen": { "never": true } }] } ``` </details>

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/membersPatchInput"
      },
      "example": {
        "comment": "Optional comment about the update",
        "instructions": [
          {
            "kind": "replaceMembersRoles",
            "value": "reader",
            "memberIDs": [
              "1234a56b7c89d012345e678f",
              "507f1f77bcf86cd799439011"
            ]
          }
        ]
      }
    }
  },
  "required": true
}

Get a time-series array of the number of monthly data export events from your account. The granularity is always daily, with a maximum of 31 days.

Get time-series arrays of the number of times a flag is evaluated, broken down by the variation that resulted from that evaluation. The granularity of the data depends on the age of the data requested. If the requested range is within the past two hours, minutely data is returned. If it is within the last two days, hourly data is returned. Otherwise, daily data is returned.

Get time-series arrays of the number of times a flag is evaluated, broken down by the variation that resulted from that evaluation. The granularity of the data depends on the age of the data requested. If the requested range is within the past two hours, minutely data is returned. If it is within the last two days, hourly data is returned. Otherwise, daily data is returned.

Get a time-series array of the number of monthly experimentation keys from your account. The granularity is always daily, with a maximum of 31 days.

Get a time-series array of the number of monthly experimentation units from your account. The granularity is always daily, with a maximum of 31 days.

Get a time-series array of the number of monthly active users (MAU) seen by LaunchDarkly from your account. The granularity is always daily.<br/><br/>Endpoints for retrieving monthly active users (MAU) do not return information about active context instances. After you have upgraded your LaunchDarkly SDK to use contexts instead of users, you should not rely on this endpoint. To learn more, read [Account usage metrics](https://docs.launchdarkly.com/home/billing/usage-metrics).

Get time-series arrays of the number of monthly active users (MAU) seen by LaunchDarkly from your account, broken down by the category of users. The category is either `browser`, `mobile`, or `backend`.<br/><br/>Endpoints for retrieving monthly active users (MAU) do not return information about active context instances. After you have upgraded your LaunchDarkly SDK to use contexts instead of users, you should not rely on this endpoint. To learn more, read [Account usage metrics](https://docs.launchdarkly.com/home/billing/usage-metrics).

Get a list of SDKs. These are all of the SDKs that have connected to LaunchDarkly by monthly active users (MAU) in the requested time period.<br/><br/>Endpoints for retrieving monthly active users (MAU) do not return information about active context instances. After you have upgraded your LaunchDarkly SDK to use contexts instead of users, you should not rely on this endpoint. To learn more, read [Account usage metrics](https://docs.launchdarkly.com/home/billing/usage-metrics).

Get a time-series array of the number of monthly service connections from your account. The granularity is always daily, with a maximum of 31 days.

Get a time-series array of the number of streaming connections to LaunchDarkly in each time period. The granularity of the data depends on the age of the data requested. If the requested range is within the past two hours, minutely data is returned. If it is within the last two days, hourly data is returned. Otherwise, daily data is returned.

Get multiple series of the number of streaming connections to LaunchDarkly in each time period, separated by SDK type and version. Information about each series is in the metadata array. The granularity of the data depends on the age of the data requested. If the requested range is within the past 2 hours, minutely data is returned. If it is within the last two days, hourly data is returned. Otherwise, daily data is returned.

Get a list of SDK version objects, which contain an SDK name and version. These are all of the SDKs that have connected to LaunchDarkly from your account in the past 60 days.

Get a list of applications. ### Expanding the applications response LaunchDarkly supports expanding the "Get applications" response to include additional fields. To expand the response, append the `expand` query parameter and include the following: * `flags` includes details on the flags that have been evaluated by the application For example, use `?expand=flags` to include the `flags` field in the response. By default, this field is **not** included in the response.

Delete an application.

Retrieve an application by the application key. ### Expanding the application response LaunchDarkly supports expanding the "Get application" response to include additional fields. To expand the response, append the `expand` query parameter and include the following: * `flags` includes details on the flags that have been evaluated by the application For example, use `?expand=flags` to include the `flags` field in the response. By default, this field is **not** included in the response.

Update an application. You can update the `description` and `kind` fields. Requires a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) representation of the desired changes to the application. To learn more, read [Updates](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/description",
          "value": "Updated description"
        }
      ]
    }
  },
  "required": true
}

Get a list of versions for a specific application in an account.

Delete an application version.

Update an application version. You can update the `supported` field. Requires a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) representation of the desired changes to the application version. To learn more, read [Updates](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/supported",
          "value": "false"
        }
      ]
    }
  },
  "required": true
}

Get all approval requests. ### Filtering approvals LaunchDarkly supports the `filter` query param for filtering, with the following fields: - `notifyMemberIds` filters for only approvals that are assigned to a member in the specified list. For example: `filter=notifyMemberIds anyOf ["memberId1", "memberId2"]`. - `requestorId` filters for only approvals that correspond to the ID of the member who requested the approval. For example: `filter=requestorId equals 457034721476302714390214`. - `resourceId` filters for only approvals that correspond to the the specified resource identifier. For example: `filter=resourceId equals proj/my-project:env/my-environment:flag/my-flag`. - `reviewStatus` filters for only approvals which correspond to the review status in the specified list. The possible values are `approved`, `declined`, and `pending`. For example: `filter=reviewStatus anyOf ["pending", "approved"]`. - `status` filters for only approvals which correspond to the status in the specified list. The possible values are `pending`, `scheduled`, `failed`, and `completed`. For example: `filter=status anyOf ["pending", "scheduled"]`. You can also apply multiple filters at once. For example, setting `filter=projectKey equals my-project, reviewStatus anyOf ["pending","approved"]` matches approval requests which correspond to the `my-project` project key, and a review status of either `pending` or `approved`. ### Expanding approval response LaunchDarkly supports the `expand` query param to include additional fields in the response, with the following fields: - `flag` includes the flag the approval request belongs to - `project` includes the project the approval request belongs to - `environments` includes the environments the approval request relates to For example, `expand=project,flag` includes the `project` and `flag` fields in the response.

Create an approval request. This endpoint currently supports creating an approval request for a flag across all environments with the following instructions: - `addVariation` - `removeVariation` - `updateVariation` - `updateDefaultVariation` For details on using these instructions, read [Update feature flag](https://apidocs.launchdarkly.com). To create an approval for a flag specific to an environment, use [Create approval request for a flag](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/createApprovalRequestRequest"
      }
    }
  },
  "required": true
}

Delete an approval request.

Get an approval request by approval request ID. ### Expanding approval response LaunchDarkly supports the `expand` query param to include additional fields in the response, with the following fields: - `flag` includes the flag the approval request belongs to - `project` includes the project the approval request belongs to - `environments` includes the environments the approval request relates to For example, `expand=project,flag` includes the `project` and `flag` fields in the response.

Apply an approval request that has been approved.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/postApprovalRequestApplyRequest"
      }
    }
  },
  "required": true
}

Review an approval request by approving or denying changes.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/postApprovalRequestReviewRequest"
      }
    }
  },
  "required": true
}

Get all approval requests for a feature flag.

Create an approval request for a feature flag.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/createFlagConfigApprovalRequestRequest"
      }
    }
  },
  "required": true
}

Create an approval request to copy a feature flag's configuration across environments.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/createCopyFlagConfigApprovalRequestRequest"
      }
    }
  },
  "required": true
}

Delete an approval request for a feature flag.

Get a single approval request for a feature flag.

Apply an approval request that has been approved.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/postApprovalRequestApplyRequest"
      }
    }
  },
  "required": true
}

Review an approval request by approving or denying changes.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/postApprovalRequestReviewRequest"
      }
    }
  },
  "required": true
}

Get a list of all audit log entries. The query parameters let you restrict the results that return by date ranges, resource specifiers, or a full-text search query. LaunchDarkly uses a resource specifier syntax to name resources or collections of resources. To learn more, read [Understanding the resource specifier syntax](https://docs.launchdarkly.com/home/members/role-resources#understanding-the-resource-specifier-syntax).

Fetch a detailed audit log entry representation. The detailed representation includes several fields that are not present in the summary representation, including: - `delta`: the JSON patch body that was used in the request to update the entity - `previousVersion`: a JSON representation of the previous version of the entity - `currentVersion`: a JSON representation of the current version of the entity

Get a list of all extinctions. LaunchDarkly creates an extinction event after you remove all code references to a flag. To learn more, read [Understanding extinction events](https://docs.launchdarkly.com/home/code/code-references#understanding-extinction-events).

Get a list of connected repositories. Optionally, you can include branch metadata with the `withBranches` query parameter. Embed references for the default branch with `ReferencesForDefaultBranch`. You can also filter the list of code references by project key and flag key.

Create a repository with the specified name.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/repositoryPost"
      }
    }
  },
  "required": true
}

Delete a repository with the specified name.

Get a single repository by name.

Update a repository's settings. Updating repository settings uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) or [JSON merge patch](https://datatracker.ietf.org/doc/html/rfc7386) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/defaultBranch",
          "value": "main"
        }
      ]
    }
  },
  "required": true
}

Asynchronously delete a number of branches.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/CodeReferencesAsynchronouslyDeleteBranchesRequest"
      },
      "example": [
        "branch-to-be-deleted",
        "another-branch-to-be-deleted"
      ]
    }
  },
  "required": true
}

Get a list of branches.

Get a specific branch in a repository.

Create a new branch if it doesn't exist, or update the branch if it already exists.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/putBranch"
      }
    }
  },
  "required": true
}

Create a new extinction.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ExtinctionListPost"
      }
    }
  },
  "required": true
}

Get links for all projects that have code references.

Get statistics about all the code references across repositories for all flags in your project that have code references in the default branch, for example, `main`. Optionally, you can include the `flagKey` query parameter to limit your request to statistics about code references for a single flag. This endpoint returns the number of references to your flag keys in your repositories, as well as a link to each repository.

Enable or disable a feature flag for a context based on its context kind and key. Omitting the `setting` attribute from the request body, or including a `setting` of `null`, erases the current setting for a context. If you previously patched the flag, and the patch included the context's data, LaunchDarkly continues to use that data. If LaunchDarkly has never encountered the combination of the context's key and kind before, it calculates the flag values based on the context kind and key.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ValuePut"
      }
    }
  },
  "required": true
}

Get all context kinds for a given project.

Create or update a context kind by key. Only the included fields will be updated.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/UpsertContextKindPayload"
      }
    }
  },
  "required": true
}

Get context attribute names. Returns only the first 100 attribute names per context.

Get context attribute values.

Search for context instances. You can use either the query parameters or the request body parameters. If both are provided, there is an error. To learn more about the filter syntax, read [Filtering contexts and context instances](https://apidocs.launchdarkly.com). To learn more about context instances, read [Understanding context instances](https://docs.launchdarkly.com/home/contexts#understanding-context-instances).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ContextInstanceSearch"
      }
    }
  },
  "required": true
}

Delete context instances by ID.

Get context instances by ID.

Search for contexts. You can use either the query parameters or the request body parameters. If both are provided, there is an error. To learn more about the filter syntax, read [Filtering contexts and context instances](https://apidocs.launchdarkly.com). To learn more about contexts, read [Understanding contexts and context kinds](https://docs.launchdarkly.com/home/contexts#understanding-contexts-and-context-kinds).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ContextSearch"
      }
    }
  },
  "required": true
}

Get contexts based on kind and key.

Evaluate flags for a context instance, for example, to determine the expected flag variation. **Do not use this API instead of an SDK.** The LaunchDarkly SDKs are specialized for the tasks of evaluating feature flags in your application at scale and generating analytics events based on those evaluations. This API is not designed for that use case. Any evaluations you perform with this API will not be reflected in features such as flag statuses and flag insights. Context instances evaluated by this API will not appear in the Contexts list. To learn more, read [Comparing LaunchDarkly's SDKs and REST API](https://docs.launchdarkly.com/guide/api/comparing-sdk-rest-api). ### Filtering LaunchDarkly supports the `filter` query param for filtering, with the following fields: - `query` filters for a string that matches against the flags' keys and names. It is not case sensitive. For example: `filter=query equals dark-mode`. - `tags` filters the list to flags that have all of the tags in the list. For example: `filter=tags contains ["beta","q1"]`. You can also apply multiple filters at once. For example, setting `filter=query equals dark-mode, tags contains ["beta","q1"]` matches flags which match the key or name `dark-mode` and are tagged `beta` and `q1`.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ContextInstance"
      },
      "example": {
        "key": "user-key-123abc",
        "kind": "user",
        "otherAttribute": "other attribute value"
      }
    }
  },
  "required": true
}

Get a complete list of custom roles. Custom roles let you create flexible policies providing fine-grained access control to everything in LaunchDarkly, from feature flags to goals, environments, and teams. With custom roles, it's possible to enforce access policies that meet your exact workflow needs. Custom roles are available to customers on our enterprise plans. If you're interested in learning more about our enterprise plans, contact sales@launchdarkly.com.

Create a new custom role

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/CustomRolePost"
      },
      "example": {
        "key": "role-key-123abc",
        "name": "Ops team",
        "policy": [
          {
            "effect": "allow",
            "actions": [
              "updateOn"
            ],
            "resources": [
              "proj/*:env/production:flag/*"
            ]
          }
        ],
        "description": "An example role for members of the ops team",
        "basePermissions": "reader"
      }
    }
  },
  "required": true
}

Delete a custom role by key

Get a single custom role by key or ID

Update a single custom role. Updating a custom role uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) or [JSON merge patch](https://datatracker.ietf.org/doc/html/rfc7386) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com).<br/><br/>To add an element to the `policy` array, set the `path` to `/policy` and then append `/<array index>`. Use `/0` to add to the beginning of the array. Use `/-` to add to the end of the array.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/PatchWithComment"
      },
      "example": {
        "patch": [
          {
            "op": "add",
            "path": "/policy/0",
            "value": {
              "effect": "allow",
              "actions": [
                "updateOn"
              ],
              "resources": [
                "proj/*:env/qa:flag/*"
              ]
            }
          }
        ]
      }
    }
  },
  "required": true
}

Get a list of Data Export destinations configured across all projects and environments.

Create a new Data Export destination. In the `config` request body parameter, the fields required depend on the type of Data Export destination. <details> <summary>Click to expand <code>config</code> parameter details</summary> #### Azure Event Hubs To create a Data Export destination with a `kind` of `azure-event-hubs`, the `config` object requires the following fields: * `namespace`: The Event Hub Namespace name * `name`: The Event Hub name * `policyName`: The shared access signature policy name. You can find your policy name in the settings of your Azure Event Hubs Namespace. * `policyKey`: The shared access signature key. You can find your policy key in the settings of your Azure Event Hubs Namespace. #### Google Cloud Pub/Sub To create a Data Export destination with a `kind` of `google-pubsub`, the `config` object requires the following fields: * `project`: The Google PubSub project ID for the project to publish to * `topic`: The Google PubSub topic ID for the topic to publish to #### Amazon Kinesis To create a Data Export destination with a `kind` of `kinesis`, the `config` object requires the following fields: * `region`: The Kinesis stream's AWS region key * `roleArn`: The Amazon Resource Name (ARN) of the AWS role that will be writing to Kinesis * `streamName`: The name of the Kinesis stream that LaunchDarkly is sending events to. This is not the ARN of the stream. #### mParticle To create a Data Export destination with a `kind` of `mparticle`, the `config` object requires the following fields: * `apiKey`: The mParticle API key * `secret`: The mParticle API secret * `userIdentity`: The type of identifier you use to identify your end users in mParticle * `anonymousUserIdentity`: The type of identifier you use to identify your anonymous end users in mParticle #### Segment To create a Data Export destination with a `kind` of `segment`, the `config` object requires the following fields: * `writeKey`: The Segment write key. This is used to authenticate LaunchDarkly's calls to Segment. </details>

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/DestinationPost"
      },
      "example": {
        "kind": "google-pubsub",
        "config": {
          "topic": "ld-pubsub-test-192301",
          "project": "test-prod"
        }
      }
    }
  },
  "required": true
}

Delete a Data Export destination by ID.

Get a single Data Export destination by ID.

Update a Data Export destination. Updating a destination uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) or [JSON merge patch](https://datatracker.ietf.org/doc/html/rfc7386) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/config/topic",
          "value": "ld-pubsub-test-192302"
        }
      ]
    }
  },
  "required": true
}

Return a list of environments for the specified project. By default, this returns the first 20 environments. Page through this list with the `limit` parameter and by following the `first`, `prev`, `next`, and `last` links in the `_links` field that returns. If those links do not appear, the pages they refer to don't exist. For example, the `first` and `prev` links will be missing from the response on the first page, because there is no previous page and you cannot return to the first page when you are already on the first page. ### Filtering environments LaunchDarkly supports two fields for filters: - `query` is a string that matches against the environments' names and keys. It is not case sensitive. - `tags` is a `+`-separated list of environment tags. It filters the list of environments that have all of the tags in the list. For example, the filter `filter=query:abc,tags:tag-1+tag-2` matches environments with the string `abc` in their name or key and also are tagged with `tag-1` and `tag-2`. The filter is not case-sensitive. The documented values for `filter` query parameters are prior to URL encoding. For example, the `+` in `filter=tags:tag-1+tag-2` must be encoded to `%2B`. ### Sorting environments LaunchDarkly supports the following fields for sorting: - `createdOn` sorts by the creation date of the environment. - `critical` sorts by whether the environments are marked as critical. - `name` sorts by environment name. For example, `sort=name` sorts the response by environment name in ascending order.

> ### Approval settings > > The `approvalSettings` key is only returned when the Flag Approvals feature is enabled. > > You cannot update approval settings when creating new environments. Update approval settings with the PATCH Environment API. Create a new environment in a specified project with a given name, key, swatch color, and default TTL.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/EnvironmentPost"
      },
      "example": {
        "key": "environment-key-123abc",
        "name": "My Environment",
        "color": "DADBEE"
      }
    }
  },
  "required": true
}

Delete a environment by key.

> ### Approval settings > > The `approvalSettings` key is only returned when the Flag Approvals feature is enabled. Get an environment given a project and key.

Update an environment. Updating an environment uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com). To update fields in the environment object that are arrays, set the `path` to the name of the field and then append `/<array index>`. Using `/0` appends to the beginning of the array. ### Approval settings This request only returns the `approvalSettings` key if the [Flag Approvals](https://docs.launchdarkly.com/home/feature-workflows/approvals) feature is enabled. Only the `canReviewOwnRequest`, `canApplyDeclinedChanges`, `minNumApprovals`, `required` and `requiredApprovalTagsfields` are editable. If you try to patch the environment by setting both `required` and `requiredApprovalTags`, the request fails and an error appears. You can specify either required approvals for all flags in an environment or those with specific tags, but not both.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/requireComments",
          "value": true
        }
      ]
    }
  },
  "required": true
}

Reset an environment's SDK key with an optional expiry time for the old key.

Reset an environment's mobile key. The optional expiry for the old key is deprecated for this endpoint, so the old key will always expire immediately.

Get details about all experiments in an environment. ### Filtering experiments LaunchDarkly supports the `filter` query param for filtering, with the following fields: - `flagKey` filters for only experiments that use the flag with the given key. - `metricKey` filters for only experiments that use the metric with the given key. - `status` filters for only experiments with an iteration with the given status. An iteration can have the status `not_started`, `running` or `stopped`. For example, `filter=flagKey:my-flag,status:running,metricKey:page-load-ms` filters for experiments for the given flag key and the given metric key which have a currently running iteration. ### Expanding the experiments response LaunchDarkly supports four fields for expanding the "Get experiments" response. By default, these fields are **not** included in the response. To expand the response, append the `expand` query parameter and add a comma-separated list with any of the following fields: - `previousIterations` includes all iterations prior to the current iteration. By default only the current iteration is included in the response. - `draftIteration` includes the iteration which has not been started yet, if any. - `secondaryMetrics` includes secondary metrics. By default only the primary metric is included in the response. - `treatments` includes all treatment and parameter details. By default treatment data is not included in the response. For example, `expand=draftIteration,treatments` includes the `draftIteration` and `treatments` fields in the response. If fields that you request with the `expand` query parameter are empty, they are not included in the response.

Create an experiment. To run this experiment, you'll need to [create an iteration](https://apidocs.launchdarkly.com)#operation/createIteration) and then [update the experiment](https://apidocs.launchdarkly.com)#operation/patchExperiment) with the `startIteration` instruction. To learn more, read [Creating experiments](https://docs.launchdarkly.com/home/creating-experiments).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ExperimentPost"
      }
    }
  },
  "required": true
}

Get details about an experiment. ### Expanding the experiment response LaunchDarkly supports four fields for expanding the "Get experiment" response. By default, these fields are **not** included in the response. To expand the response, append the `expand` query parameter and add a comma-separated list with any of the following fields: - `previousIterations` includes all iterations prior to the current iteration. By default only the current iteration is included in the response. - `draftIteration` includes the iteration which has not been started yet, if any. - `secondaryMetrics` includes secondary metrics. By default only the primary metric is included in the response. - `treatments` includes all treatment and parameter details. By default treatment data is not included in the response. For example, `expand=draftIteration,treatments` includes the `draftIteration` and `treatments` fields in the response. If fields that you request with the `expand` query parameter are empty, they are not included in the response.

Update an experiment. Updating an experiment uses the semantic patch format. To make a semantic patch request, you must append `domain-model=launchdarkly.semanticpatch` to your `Content-Type` header. To learn more, read [Updates using semantic patch](https://apidocs.launchdarkly.com). ### Instructions Semantic patch requests support the following `kind` instructions for updating experiments. #### updateName Updates the experiment name. ##### Parameters - `value`: The new name. Here's an example: ```json { "instructions": [{ "kind": "updateName", "value": "Example updated experiment name" }] } ``` #### updateDescription Updates the experiment description. ##### Parameters - `value`: The new description. Here's an example: ```json { "instructions": [{ "kind": "updateDescription", "value": "Example updated description" }] } ``` #### startIteration Starts a new iteration for this experiment. You must [create a new iteration](https://apidocs.launchdarkly.com)#operation/createIteration) before calling this instruction. An iteration may not be started until it meets the following criteria: * Its associated flag is toggled on and is not archived * Its `randomizationUnit` is set * At least one of its `treatments` has a non-zero `allocationPercent` ##### Parameters - `changeJustification`: The reason for starting a new iteration. Required when you call `startIteration` on an already running experiment, otherwise optional. Here's an example: ```json { "instructions": [{ "kind": "startIteration", "changeJustification": "It's time to start a new iteration" }] } ``` #### stopIteration Stops the current iteration for this experiment. ##### Parameters - `winningTreatmentId`: The ID of the winning treatment. Treatment IDs are returned as part of the [Get experiment](https://apidocs.launchdarkly.com)#operation/getExperiment) response. They are the `_id` of each element in the `treatments` array. - `winningReason`: The reason for the winner Here's an example: ```json { "instructions": [{ "kind": "stopIteration", "winningTreatmentId": "3a548ec2-72ac-4e59-8518-5c24f5609ccf", "winningReason": "Example reason to stop the iteration" }] } ``` #### archiveExperiment Archives this experiment. Archived experiments are hidden by default in the LaunchDarkly user interface. You cannot start new iterations for archived experiments. Here's an example: ```json { "instructions": [{ "kind": "archiveExperiment" }] } ``` #### restoreExperiment Restores an archived experiment. After restoring an experiment, you can start new iterations for it again. Here's an example: ```json { "instructions": [{ "kind": "restoreExperiment" }] } ```

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/ExperimentPatchInput"
      },
      "example": {
        "comment": "Example comment describing the update",
        "instructions": [
          {
            "kind": "updateName",
            "value": "Updated experiment name"
          }
        ]
      }
    }
  },
  "required": true
}

Create an experiment iteration. Experiment iterations let you record experiments in individual blocks of time. Initially, iterations are created with a status of `not_started` and appear in the `draftIteration` field of an experiment. To start or stop an iteration, [update the experiment](https://apidocs.launchdarkly.com)#operation/patchExperiment) with the `startIteration` or `stopIteration` instruction. To learn more, read [Starting experiment iterations](https://docs.launchdarkly.com/home/creating-experiments#starting-experiment-iterations).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/IterationInput"
      }
    }
  },
  "required": true
}

Get results from an experiment for a particular metric group.

Get results from an experiment for a particular metric. LaunchDarkly supports one field for expanding the "Get experiment results" response. By default, this field is **not** included in the response. To expand the response, append the `expand` query parameter with the following field: * `traffic` includes the total count of units for each treatment. For example, `expand=traffic` includes the `traffic` field for the project in the response.

Get current experimentation settings for the given project

Update experimentation settings for the given project

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/RandomizationSettingsPut"
      }
    }
  },
  "required": true
}

Get the status for a particular feature flag across environments.

Get a list of statuses for all feature flags. The status includes the last time the feature flag was requested, as well as a state, which is one of the following: - `new`: You created the flag fewer than seven days ago and it has never been requested. - `active`: LaunchDarkly is receiving requests for this flag, but there are either multiple variations configured, or it is toggled off, or there have been changes to configuration in the past seven days. - `inactive`: You created the feature flag more than seven days ago, and hasn't been requested within the past seven days. - `launched`: LaunchDarkly is receiving requests for this flag, it is toggled on, there is only one variation configured, and there have been no changes to configuration in the past seven days. To learn more, read [Flag statuses](https://docs.launchdarkly.com/home/code/flag-status).

Get the status for a particular feature flag.

Get a list of all feature flags in the given project. By default, each flag includes configurations for each environment. You can filter environments with the `env` query parameter. For example, setting `env=production` restricts the returned configurations to just your production environment. You can also filter feature flags by tag with the `tag` query parameter. > #### Recommended use > > This endpoint can return a large amount of information. We recommend using some or all of these query parameters to decrease response time and overall payload size: `limit`, `env`, `query`, and `filter=creationDate`. ### Filtering flags You can filter on certain fields using the `filter` query parameter. For example, setting `filter=query:dark-mode,tags:beta+test` matches flags with the string `dark-mode` in their key or name, ignoring case, which also have the tags `beta` and `test`. The `filter` query parameter supports the following arguments: | Filter argument | Description | Example | |-----------------------|-------------|----------------------| | `applicationEvaluated` | A string. It filters the list to flags that are evaluated in the application with the given key. | `filter=applicationEvaluated:com.launchdarkly.cafe` | | `archived` | (deprecated) A boolean value. It filters the list to archived flags. | Use `filter=state:archived` instead | | `contextKindsEvaluated` | A `+`-separated list of context kind keys. It filters the list to flags which have been evaluated in the past 30 days for all of the context kinds in the list. | `filter=contextKindsEvaluated:user+application` | | `codeReferences.max` | An integer value. Use `0` to return flags that do not have code references. | `filter=codeReferences.max:0` | | `codeReferences.min` | An integer value. Use `1` to return flags that do have code references. | `filter=codeReferences.min:1` | | `creationDate` | An object with an optional `before` field whose value is Unix time in milliseconds. It filters the list to flags created before the date. | `filter=creationDate:{"before":1690527600000}` | | `evaluated` | An object that contains a key of `after` and a value in Unix time in milliseconds. It filters the list to all flags that have been evaluated since the time you specify, in the environment provided. This filter requires the `filterEnv` filter. | `filter=evaluation:{"after":1690527600000}` | | `filterEnv` | A string with a list of comma-separated keys of valid environments. You must use this field for filters that are environment-specific. If there are multiple environment-specific filters, you only need to include this field once. You can filter for a maximum of three environments. | `filter=evaluated:{"after": 1590768455282},filterEnv:production,status:active` | | `hasExperiment` | A boolean value. It filters the list to flags that are used in an experiment. | `filter=hasExperiment:true` | | `maintainerId` | A valid member ID. It filters the list to flags that are maintained by this member. | `filter=maintainerId:12ab3c45de678910abc12345` | | `maintainerTeamKey` | A string. It filters the list to flags that are maintained by the team with this key. | `filter=maintainerTeamKey:example-team-key` | | `query` | A string. It filters the list to flags that include the specified string in their key or name. It is not case sensitive. | `filter=query:example` | | `state` | A string, either `live`, `deprecated`, or `archived`. It filters the list to flags in this state. | `filter=state:archived` | | `sdkAvailability` | A string, one of `client`, `mobile`, `anyClient`, `server`. Using `client` filters the list to flags whose client-side SDK availability is set to use the client-side ID. Using `mobile` filters to flags set to use the mobile key. Using `anyClient` filters to flags set to use either the client-side ID or the mobile key. Using `server` filters to flags set to use neither, that is, to flags only available in server-side SDKs. | `filter=sdkAvailability:client` | | `tags` | A `+`-separated list of tags. It filters the list to flags that have all of the tags in the list. | `filter=tags:beta+test` | | `type` | A string, either `temporary` or `permanent`. It filters the list to flags with the specified type. | `filter=type:permanent` | The documented values for the `filter` query are prior to URL encoding. For example, the `+` in `filter=tags:beta+test` must be encoded to `%2B`. By default, this endpoint returns all flags. You can page through the list with the `limit` parameter and by following the `first`, `prev`, `next`, and `last` links in the returned `_links` field. These links will not be present if the pages they refer to don't exist. For example, the `first` and `prev` links will be missing from the response on the first page. ### Sorting flags You can sort flags based on the following fields: - `creationDate` sorts by the creation date of the flag. - `key` sorts by the key of the flag. - `maintainerId` sorts by the flag maintainer. - `name` sorts by flag name. - `tags` sorts by tags. - `targetingModifiedDate` sorts by the date that the flag's targeting rules were last modified in a given environment. It must be used with `env` parameter and it can not be combined with any other sort. If multiple `env` values are provided, it will perform sort using the first one. For example, `sort=-targetingModifiedDate&env=production&env=staging` returns results sorted by `targetingModifiedDate` for the `production` environment. - `type` sorts by flag type All fields are sorted in ascending order by default. To sort in descending order, prefix the field with a dash ( - ). For example, `sort=-name` sorts the response by flag name in descending order. ### Expanding response LaunchDarkly supports the `expand` query param to include additional fields in the response, with the following fields: - `codeReferences` includes code references for the feature flag - `evaluation` includes evaluation information within returned environments, including which context kinds the flag has been evaluated for in the past 30 days - `migrationSettings` includes migration settings information within the flag and within returned environments. These settings are only included for migration flags, that is, where `purpose` is `migration`. For example, `expand=evaluation` includes the `evaluation` field in the response. ### Migration flags For migration flags, the cohort information is included in the `rules` property of a flag's response, and default cohort information is included in the `fallthrough` property of a flag's response. To learn more, read [Migration Flags](https://docs.launchdarkly.com/home/flag-types/migration-flags).

Create a feature flag with the given name, key, and variations. <details> <summary>Click to expand instructions for <strong>creating a migration flag</strong></summary> ### Creating a migration flag When you create a migration flag, the variations are pre-determined based on the number of stages in the migration. To create a migration flag, omit the `variations` and `defaults` information. Instead, provide a `purpose` of `migration`, and `migrationSettings`. If you create a migration flag with six stages, `contextKind` is required. Otherwise, it should be omitted. Here's an example: ```json { "key": "flag-key-123", "purpose": "migration", "migrationSettings": { "stageCount": 6, "contextKind": "account" } } ``` To learn more, read [Migration Flags](https://docs.launchdarkly.com/home/flag-types/migration-flags). </details>

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/FeatureFlagBody"
      },
      "example": {
        "key": "flag-key-123abc",
        "name": "My Flag",
        "clientSideAvailability": {
          "usingMobileKey": true,
          "usingEnvironmentId": true
        }
      }
    }
  },
  "required": true
}

Delete a feature flag in all environments. Use with caution: only delete feature flags your application no longer uses.

Get a single feature flag by key. By default, this returns the configurations for all environments. You can filter environments with the `env` query parameter. For example, setting `env=production` restricts the returned configurations to just the `production` environment. > #### Recommended use > > This endpoint can return a large amount of information. Specifying one or multiple environments with the `env` parameter can decrease response time and overall payload size. We recommend using this parameter to return only the environments relevant to your query. ### Expanding response LaunchDarkly supports the `expand` query param to include additional fields in the response, with the following fields: - `evaluation` includes evaluation information within returned environments, including which context kinds the flag has been evaluated for in the past 30 days - `migrationSettings` includes migration settings information within the flag and within returned environments. These settings are only included for migration flags, that is, where `purpose` is `migration`. For example, `expand=evaluation` includes the `evaluation` field in the response.

Perform a partial update to a feature flag. The request body must be a valid semantic patch, JSON patch, or JSON merge patch. To learn more the different formats, read [Updates](https://apidocs.launchdarkly.com). ### Using semantic patches on a feature flag To make a semantic patch request, you must append `domain-model=launchdarkly.semanticpatch` to your `Content-Type` header. To learn more, read [Updates using semantic patch](https://apidocs.launchdarkly.com). The body of a semantic patch request for updating feature flags takes the following properties: * `comment` (string): (Optional) A description of the update. * `environmentKey` (string): (Required for some instructions only) The key of the LaunchDarkly environment. * `instructions` (array): (Required) A list of actions the update should perform. Each action in the list must be an object with a `kind` property that indicates the instruction. If the action requires parameters, you must include those parameters as additional fields in the object. The body of a single semantic patch can contain many different instructions. ### Instructions Semantic patch requests support the following `kind` instructions for updating feature flags. <details> <summary>Click to expand instructions for <strong>turning flags on and off</strong></summary> These instructions require the `environmentKey` parameter. #### turnFlagOff Sets the flag's targeting state to **Off**. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "turnFlagOff" } ] } ``` #### turnFlagOn Sets the flag's targeting state to **On**. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "turnFlagOn" } ] } ``` </details><br /> <details> <summary>Click to expand instructions for <strong>working with targeting and variations</strong></summary> These instructions require the `environmentKey` parameter. Several of the instructions for working with targeting and variations require flag rule IDs, variation IDs, or clause IDs as parameters. Each of these are returned as part of the [Get feature flag](https://apidocs.launchdarkly.com) response. The flag rule ID is the `_id` field of each element in the `rules` array within each environment listed in the `environments` object. The variation ID is the `_id` field in each element of the `variations` array. The clause ID is the `_id` field of each element of the `clauses` array within the `rules` array within each environment listed in the `environments` object. #### addClauses Adds the given clauses to the rule indicated by `ruleId`. ##### Parameters - `ruleId`: ID of a rule in the flag. - `clauses`: Array of clause objects, with `contextKind` (string), `attribute` (string), `op` (string), `negate` (boolean), and `values` (array of strings, numbers, or dates) properties. The `contextKind`, `attribute`, and `values` are case sensitive. The `op` must be lower-case. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addClauses", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "clauses": [{ "contextKind": "user", "attribute": "country", "op": "in", "negate": false, "values": ["USA", "Canada"] }] }] } ``` #### addPrerequisite Adds the flag indicated by `key` with variation `variationId` as a prerequisite to the flag in the path parameter. ##### Parameters - `key`: Flag key of the prerequisite flag. - `variationId`: ID of a variation of the prerequisite flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addPrerequisite", "key": "example-prereq-flag-key", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### addRule Adds a new targeting rule to the flag. The rule may contain `clauses` and serve the variation that `variationId` indicates, or serve a percentage rollout that `rolloutWeights`, `rolloutBucketBy`, and `rolloutContextKind` indicate. If you set `beforeRuleId`, this adds the new rule before the indicated rule. Otherwise, adds the new rule to the end of the list. ##### Parameters - `clauses`: Array of clause objects, with `contextKind` (string), `attribute` (string), `op` (string), `negate` (boolean), and `values` (array of strings, numbers, or dates) properties. The `contextKind`, `attribute`, and `values` are case sensitive. The `op` must be lower-case. - `beforeRuleId`: (Optional) ID of a flag rule. - Either - `variationId`: ID of a variation of the flag. or - `rolloutWeights`: (Optional) Map of `variationId` to weight, in thousandths of a percent (0-100000). - `rolloutBucketBy`: (Optional) Context attribute available in the specified `rolloutContextKind`. - `rolloutContextKind`: (Optional) Context kind, defaults to `user` Here's an example that uses a `variationId`: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addRule", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00", "clauses": [{ "contextKind": "organization", "attribute": "located_in", "op": "in", "negate": false, "values": ["Sweden", "Norway"] }] }] } ``` Here's an example that uses a percentage rollout: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addRule", "clauses": [{ "contextKind": "organization", "attribute": "located_in", "op": "in", "negate": false, "values": ["Sweden", "Norway"] }], "rolloutContextKind": "organization", "rolloutWeights": { "2f43f67c-3e4e-4945-a18a-26559378ca00": 15000, // serve 15% this variation "e5830889-1ec5-4b0c-9cc9-c48790090c43": 85000 // serve 85% this variation } }] } ``` #### addTargets Adds context keys to the individual context targets for the context kind that `contextKind` specifies and the variation that `variationId` specifies. Returns an error if this causes the flag to target the same context key in multiple variations. ##### Parameters - `values`: List of context keys. - `contextKind`: (Optional) Context kind to target, defaults to `user` - `variationId`: ID of a variation on the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addTargets", "values": ["context-key-123abc", "context-key-456def"], "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### addUserTargets Adds user keys to the individual user targets for the variation that `variationId` specifies. Returns an error if this causes the flag to target the same user key in multiple variations. If you are working with contexts, use `addTargets` instead of this instruction. ##### Parameters - `values`: List of user keys. - `variationId`: ID of a variation on the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addUserTargets", "values": ["user-key-123abc", "user-key-456def"], "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### addValuesToClause Adds `values` to the values of the clause that `ruleId` and `clauseId` indicate. Does not update the context kind, attribute, or operator. ##### Parameters - `ruleId`: ID of a rule in the flag. - `clauseId`: ID of a clause in that rule. - `values`: Array of strings, case sensitive. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "addValuesToClause", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "clauseId": "10a58772-3121-400f-846b-b8a04e8944ed", "values": ["beta_testers"] }] } ``` #### addVariation Adds a variation to the flag. ##### Parameters - `value`: The variation value. - `name`: (Optional) The variation name. - `description`: (Optional) A description for the variation. Here's an example: ```json { "instructions": [ { "kind": "addVariation", "value": 20, "name": "New variation" } ] } ``` #### clearTargets Removes all individual targets from the variation that `variationId` specifies. This includes both user and non-user targets. ##### Parameters - `variationId`: ID of a variation on the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "clearTargets", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" } ] } ``` #### clearUserTargets Removes all individual user targets from the variation that `variationId` specifies. If you are working with contexts, use `clearTargets` instead of this instruction. ##### Parameters - `variationId`: ID of a variation on the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "clearUserTargets", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" } ] } ``` #### removeClauses Removes the clauses specified by `clauseIds` from the rule indicated by `ruleId`. ##### Parameters - `ruleId`: ID of a rule in the flag. - `clauseIds`: Array of IDs of clauses in the rule. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "removeClauses", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "clauseIds": ["10a58772-3121-400f-846b-b8a04e8944ed", "36a461dc-235e-4b08-97b9-73ce9365873e"] }] } ``` #### removePrerequisite Removes the prerequisite flag indicated by `key`. Does nothing if this prerequisite does not exist. ##### Parameters - `key`: Flag key of an existing prerequisite flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "removePrerequisite", "key": "prereq-flag-key-123abc" } ] } ``` #### removeRule Removes the targeting rule specified by `ruleId`. Does nothing if the rule does not exist. ##### Parameters - `ruleId`: ID of a rule in the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "removeRule", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29" } ] } ``` #### removeTargets Removes context keys from the individual context targets for the context kind that `contextKind` specifies and the variation that `variationId` specifies. Does nothing if the flag does not target the context keys. ##### Parameters - `values`: List of context keys. - `contextKind`: (Optional) Context kind to target, defaults to `user` - `variationId`: ID of a flag variation. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "removeTargets", "values": ["context-key-123abc", "context-key-456def"], "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### removeUserTargets Removes user keys from the individual user targets for the variation that `variationId` specifies. Does nothing if the flag does not target the user keys. If you are working with contexts, use `removeTargets` instead of this instruction. ##### Parameters - `values`: List of user keys. - `variationId`: ID of a flag variation. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "removeUserTargets", "values": ["user-key-123abc", "user-key-456def"], "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### removeValuesFromClause Removes `values` from the values of the clause indicated by `ruleId` and `clauseId`. Does not update the context kind, attribute, or operator. ##### Parameters - `ruleId`: ID of a rule in the flag. - `clauseId`: ID of a clause in that rule. - `values`: Array of strings, case sensitive. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "removeValuesFromClause", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "clauseId": "10a58772-3121-400f-846b-b8a04e8944ed", "values": ["beta_testers"] }] } ``` #### removeVariation Removes a variation from the flag. ##### Parameters - `variationId`: ID of a variation of the flag to remove. Here's an example: ```json { "instructions": [ { "kind": "removeVariation", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" } ] } ``` #### reorderRules Rearranges the rules to match the order given in `ruleIds`. Returns an error if `ruleIds` does not match the current set of rules on the flag. ##### Parameters - `ruleIds`: Array of IDs of all rules in the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "reorderRules", "ruleIds": ["a902ef4a-2faf-4eaf-88e1-ecc356708a29", "63c238d1-835d-435e-8f21-c8d5e40b2a3d"] }] } ``` #### replacePrerequisites Removes all existing prerequisites and replaces them with the list you provide. ##### Parameters - `prerequisites`: A list of prerequisites. Each item in the list must include a flag `key` and `variationId`. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "replacePrerequisites", "prerequisites": [ { "key": "prereq-flag-key-123abc", "variationId": "10a58772-3121-400f-846b-b8a04e8944ed" }, { "key": "another-prereq-flag-key-456def", "variationId": "e5830889-1ec5-4b0c-9cc9-c48790090c43" } ] } ] } ``` #### replaceRules Removes all targeting rules for the flag and replaces them with the list you provide. ##### Parameters - `rules`: A list of rules. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "replaceRules", "rules": [ { "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00", "description": "My new rule", "clauses": [ { "contextKind": "user", "attribute": "segmentMatch", "op": "segmentMatch", "values": ["test"] } ], "trackEvents": true } ] } ] } ``` #### replaceTargets Removes all existing targeting and replaces it with the list of targets you provide. ##### Parameters - `targets`: A list of context targeting. Each item in the list includes an optional `contextKind` that defaults to `user`, a required `variationId`, and a required list of `values`. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "replaceTargets", "targets": [ { "contextKind": "user", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00", "values": ["user-key-123abc"] }, { "contextKind": "device", "variationId": "e5830889-1ec5-4b0c-9cc9-c48790090c43", "values": ["device-key-456def"] } ] } ] } ``` #### replaceUserTargets Removes all existing user targeting and replaces it with the list of targets you provide. In the list of targets, you must include a target for each of the flag's variations. If you are working with contexts, use `replaceTargets` instead of this instruction. ##### Parameters - `targets`: A list of user targeting. Each item in the list must include a `variationId` and a list of `values`. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "replaceUserTargets", "targets": [ { "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00", "values": ["user-key-123abc", "user-key-456def"] }, { "variationId": "e5830889-1ec5-4b0c-9cc9-c48790090c43", "values": ["user-key-789ghi"] } ] } ] } ``` #### updateClause Replaces the clause indicated by `ruleId` and `clauseId` with `clause`. ##### Parameters - `ruleId`: ID of a rule in the flag. - `clauseId`: ID of a clause in that rule. - `clause`: New `clause` object, with `contextKind` (string), `attribute` (string), `op` (string), `negate` (boolean), and `values` (array of strings, numbers, or dates) properties. The `contextKind`, `attribute`, and `values` are case sensitive. The `op` must be lower-case. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updateClause", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "clauseId": "10c7462a-2062-45ba-a8bb-dfb3de0f8af5", "clause": { "contextKind": "user", "attribute": "country", "op": "in", "negate": false, "values": ["Mexico", "Canada"] } }] } ``` #### updateDefaultVariation Updates the default on or off variation of the flag. ##### Parameters - `onVariationValue`: (Optional) The value of the variation of the new on variation. - `offVariationValue`: (Optional) The value of the variation of the new off variation Here's an example: ```json { "instructions": [ { "kind": "updateDefaultVariation", "OnVariationValue": true, "OffVariationValue": false } ] } ``` #### updateFallthroughVariationOrRollout Updates the default or "fallthrough" rule for the flag, which the flag serves when a context matches none of the targeting rules. The rule can serve either the variation that `variationId` indicates, or a percentage rollout that `rolloutWeights` and `rolloutBucketBy` indicate. ##### Parameters - `variationId`: ID of a variation of the flag. or - `rolloutWeights`: Map of `variationId` to weight, in thousandths of a percent (0-100000). - `rolloutBucketBy`: (Optional) Context attribute available in the specified `rolloutContextKind`. - `rolloutContextKind`: (Optional) Context kind, defaults to `user` Here's an example that uses a `variationId`: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updateFallthroughVariationOrRollout", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` Here's an example that uses a percentage rollout: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updateFallthroughVariationOrRollout", "rolloutContextKind": "user", "rolloutWeights": { "2f43f67c-3e4e-4945-a18a-26559378ca00": 15000, // serve 15% this variation "e5830889-1ec5-4b0c-9cc9-c48790090c43": 85000 // serve 85% this variation } }] } ``` #### updateOffVariation Updates the default off variation to `variationId`. The flag serves the default off variation when the flag's targeting is **Off**. ##### Parameters - `variationId`: ID of a variation of the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "updateOffVariation", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" } ] } ``` #### updatePrerequisite Changes the prerequisite flag that `key` indicates to use the variation that `variationId` indicates. Returns an error if this prerequisite does not exist. ##### Parameters - `key`: Flag key of an existing prerequisite flag. - `variationId`: ID of a variation of the prerequisite flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updatePrerequisite", "key": "example-prereq-flag-key", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### updateRuleDescription Updates the description of the feature flag rule. ##### Parameters - `description`: The new human-readable description for this rule. - `ruleId`: The ID of the rule. You can retrieve this by making a GET request for the flag. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updateRuleDescription", "description": "New rule description", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29" }] } ``` #### updateRuleTrackEvents Updates whether or not LaunchDarkly tracks events for the feature flag associated with this rule. ##### Parameters - `ruleId`: The ID of the rule. You can retrieve this by making a GET request for the flag. - `trackEvents`: Whether or not events are tracked. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updateRuleTrackEvents", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "trackEvents": true }] } ``` #### updateRuleVariationOrRollout Updates what `ruleId` serves when its clauses evaluate to true. The rule can serve either the variation that `variationId` indicates, or a percent rollout that `rolloutWeights` and `rolloutBucketBy` indicate. ##### Parameters - `ruleId`: ID of a rule in the flag. - `variationId`: ID of a variation of the flag. or - `rolloutWeights`: Map of `variationId` to weight, in thousandths of a percent (0-100000). - `rolloutBucketBy`: (Optional) Context attribute available in the specified `rolloutContextKind`. - `rolloutContextKind`: (Optional) Context kind, defaults to `user` Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [{ "kind": "updateRuleVariationOrRollout", "ruleId": "a902ef4a-2faf-4eaf-88e1-ecc356708a29", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00" }] } ``` #### updateTrackEvents Updates whether or not LaunchDarkly tracks events for the feature flag, for all rules. ##### Parameters - `trackEvents`: Whether or not events are tracked. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "updateTrackEvents", "trackEvents": true } ] } ``` #### updateTrackEventsFallthrough Updates whether or not LaunchDarkly tracks events for the feature flag, for the default rule. ##### Parameters - `trackEvents`: Whether or not events are tracked. Here's an example: ```json { "environmentKey": "environment-key-123abc", "instructions": [ { "kind": "updateTrackEventsFallthrough", "trackEvents": true } ] } ``` #### updateVariation Updates a variation of the flag. ##### Parameters - `variationId`: The ID of the variation to update. - `name`: (Optional) The updated variation name. - `value`: (Optional) The updated variation value. - `description`: (Optional) The updated variation description. Here's an example: ```json { "instructions": [ { "kind": "updateVariation", "variationId": "2f43f67c-3e4e-4945-a18a-26559378ca00", "value": 20 } ] } ``` </details><br /> <details> <summary>Click to expand instructions for <strong>updating flag settings</strong></summary> These instructions do not require the `environmentKey` parameter. They make changes that apply to the flag across all environments. #### addCustomProperties Adds a new custom property to the feature flag. Custom properties are used to associate feature flags with LaunchDarkly integrations. For example, if you create an integration with an issue tracking service, you may want to associate a flag with a list of issues related to a feature's development. ##### Parameters - `key`: The custom property key. - `name`: The custom property name. - `values`: A list of the associated values for the custom property. Here's an example: ```json { "instructions": [{ "kind": "addCustomProperties", "key": "example-custom-property", "name": "Example custom property", "values": ["value1", "value2"] }] } ``` #### addTags Adds tags to the feature flag. ##### Parameters - `values`: A list of tags to add. Here's an example: ```json { "instructions": [ { "kind": "addTags", "values": ["tag1", "tag2"] } ] } ``` #### makeFlagPermanent Marks the feature flag as permanent. LaunchDarkly does not prompt you to remove permanent flags, even if one variation is rolled out to all your customers. Here's an example: ```json { "instructions": [ { "kind": "makeFlagPermanent" } ] } ``` #### makeFlagTemporary Marks the feature flag as temporary. Here's an example: ```json { "instructions": [ { "kind": "makeFlagTemporary" } ] } ``` #### removeCustomProperties Removes the associated values from a custom property. If all the associated values are removed, this instruction also removes the custom property. ##### Parameters - `key`: The custom property key. - `values`: A list of the associated values to remove from the custom property. ```json { "instructions": [{ "kind": "replaceCustomProperties", "key": "example-custom-property", "values": ["value1", "value2"] }] } ``` #### removeMaintainer Removes the flag's maintainer. To set a new maintainer, use the flag's **Settings** tab in the LaunchDarkly user interface. Here's an example: ```json { "instructions": [ { "kind": "removeMaintainer" } ] } ``` #### removeTags Removes tags from the feature flag. ##### Parameters - `values`: A list of tags to remove. Here's an example: ```json { "instructions": [ { "kind": "removeTags", "values": ["tag1", "tag2"] } ] } ``` #### replaceCustomProperties Replaces the existing associated values for a custom property with the new values. ##### Parameters - `key`: The custom property key. - `name`: The custom property name. - `values`: A list of the new associated values for the custom property. Here's an example: ```json { "instructions": [{ "kind": "replaceCustomProperties", "key": "example-custom-property", "name": "Example custom property", "values": ["value1", "value2"] }] } ``` #### turnOffClientSideAvailability Turns off client-side SDK availability for the flag. This is equivalent to unchecking the **SDKs using Mobile Key** and/or **SDKs using client-side ID** boxes for the flag. If you're using a client-side or mobile SDK, you must expose your feature flags in order for the client-side or mobile SDKs to evaluate them. ##### Parameters - `value`: Use "usingMobileKey" to turn off availability for mobile SDKs. Use "usingEnvironmentId" to turn on availability for client-side SDKs. Here's an example: ```json { "instructions": [ { "kind": "turnOffClientSideAvailability", "value": "usingMobileKey" } ] } ``` #### turnOnClientSideAvailability Turns on client-side SDK availability for the flag. This is equivalent to unchecking the **SDKs using Mobile Key** and/or **SDKs using client-side ID** boxes for the flag. If you're using a client-side or mobile SDK, you must expose your feature flags in order for the client-side or mobile SDKs to evaluate them. ##### Parameters - `value`: Use "usingMobileKey" to turn on availability for mobile SDKs. Use "usingEnvironmentId" to turn on availability for client-side SDKs. Here's an example: ```json { "instructions": [ { "kind": "turnOnClientSideAvailability", "value": "usingMobileKey" } ] } ``` #### updateDescription Updates the feature flag description. ##### Parameters - `value`: The new description. Here's an example: ```json { "instructions": [ { "kind": "updateDescription", "value": "Updated flag description" } ] } ``` #### updateMaintainerMember Updates the maintainer of the flag to an existing member and removes the existing maintainer. ##### Parameters - `value`: The ID of the member. Here's an example: ```json { "instructions": [ { "kind": "updateMaintainerMember", "value": "61e9b714fd47591727db558a" } ] } ``` #### updateMaintainerTeam Updates the maintainer of the flag to an existing team and removes the existing maintainer. ##### Parameters - `value`: The key of the team. Here's an example: ```json { "instructions": [ { "kind": "updateMaintainerTeam", "value": "example-team-key" } ] } ``` #### updateName Updates the feature flag name. ##### Parameters - `value`: The new name. Here's an example: ```json { "instructions": [ { "kind": "updateName", "value": "Updated flag name" } ] } ``` </details><br /> <details> <summary>Click to expand instructions for <strong>updating the flag lifecycle</strong></summary> These instructions do not require the `environmentKey` parameter. They make changes that apply to the flag across all environments. #### archiveFlag Archives the feature flag. This retires it from LaunchDarkly without deleting it. You cannot archive a flag that is a prerequisite of other flags. ```json { "instructions": [ { "kind": "archiveFlag" } ] } ``` #### deleteFlag Deletes the feature flag and its rules. You cannot restore a deleted flag. If this flag is requested again, the flag value defined in code will be returned for all contexts. Here's an example: ```json { "instructions": [ { "kind": "deleteFlag" } ] } ``` #### deprecateFlag Deprecates the feature flag. This hides it from the live flags list without archiving or deleting it. Here's an example: ```json { "instructions": [ { "kind": "deprecateFlag" } ] } ``` #### restoreDeprecatedFlag Restores the feature flag if it was previously deprecated. Here's an example: ```json { "instructions": [ { "kind": "restoreDeprecatedFlag" } ] } ``` #### restoreFlag Restores the feature flag if it was previously archived. Here's an example: ```json { "instructions": [ { "kind": "restoreFlag" } ] } ``` </details> ### Using JSON patches on a feature flag If you do not include the semantic patch header described above, you can use a [JSON patch](https://apidocs.launchdarkly.com) or [JSON merge patch](https://datatracker.ietf.org/doc/html/rfc7386) representation of the desired changes. In the JSON patch representation, use a JSON pointer in the `path` element to describe what field to change. Use the [Get feature flag](https://apidocs.launchdarkly.com) endpoint to find the field you want to update. There are a few special cases to keep in mind when determining the value of the `path` element: * To add an individual target to a specific variation if the flag variation already has individual targets, the path for the JSON patch operation is: ```json [ { "op": "add", "path": "/environments/devint/targets/0/values/-", "value": "TestClient10" } ] ``` * To add an individual target to a specific variation if the flag variation does not already have individual targets, the path for the JSON patch operation is: ```json [ { "op": "add", "path": "/environments/devint/targets/-", "value": { "variation": 0, "values": ["TestClient10"] } } ] ``` * To add a flag to a release pipeline, the path for the JSON patch operation is: ```json [ { "op": "add", "path": "/releasePipelineKey", "value": "example-release-pipeline-key" } ] ``` ### Required approvals If a request attempts to alter a flag configuration in an environment where approvals are required for the flag, the request will fail with a 405. Changes to the flag configuration in that environment will require creating an [approval request](https://apidocs.launchdarkly.com) or a [workflow](https://apidocs.launchdarkly.com). ### Conflicts If a flag configuration change made through this endpoint would cause a pending scheduled change or approval request to fail, this endpoint will return a 400. You can ignore this check by adding an `ignoreConflicts` query parameter set to `true`. ### Migration flags For migration flags, the cohort information is included in the `rules` property of a flag's response. You can update cohorts by updating `rules`. Default cohort information is included in the `fallthrough` property of a flag's response. You can update the default cohort by updating `fallthrough`. When you update the rollout for a cohort or the default cohort through the API, provide a rollout instead of a single `variationId`. To learn more, read [Migration Flags](https://docs.launchdarkly.com/home/flag-types/migration-flags).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/PatchWithComment"
      },
      "example": {
        "patch": [
          {
            "op": "replace",
            "path": "/description",
            "value": "New description for this flag"
          }
        ]
      }
    }
  },
  "required": true
}

> ### Copying flag settings is an Enterprise feature > > Copying flag settings is available to customers on an Enterprise plan. To learn more, [read about our pricing](https://launchdarkly.com/pricing/). To upgrade your plan, [contact Sales](https://launchdarkly.com/contact-sales/). Copy flag settings from a source environment to a target environment. By default, this operation copies the entire flag configuration. You can use the `includedActions` or `excludedActions` to specify that only part of the flag configuration is copied. If you provide the optional `currentVersion` of a flag, this operation tests to ensure that the current flag version in the environment matches the version you've specified. The operation rejects attempts to copy flag settings if the environment's current version of the flag does not match the version you've specified. You can use this to enforce optimistic locking on copy attempts.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/FlagCopyConfigPost"
      },
      "example": {
        "source": {
          "key": "source-env-key-123abc",
          "currentVersion": 1
        },
        "target": {
          "key": "target-env-key-123abc",
          "currentVersion": 1
        },
        "comment": "optional comment"
      }
    }
  },
  "required": true
}

Get a list of context targets on a feature flag that are scheduled for removal.

Schedule a context for removal from individual targeting on a feature flag. The flag must already individually target the context. You can add, update, or remove a scheduled removal date. You can only schedule a context for removal on a single variation per flag. Updating an expiring target uses the semantic patch format. To make a semantic patch request, you must append `domain-model=launchdarkly.semanticpatch` to your `Content-Type` header. To learn more, read [Updates using semantic patch](https://apidocs.launchdarkly.com). ### Instructions Semantic patch requests support the following `kind` instructions for updating expiring targets. <details> <summary>Click to expand instructions for <strong>updating expiring targets</strong></summary> #### addExpiringTarget Adds a date and time that LaunchDarkly will remove the context from the flag's individual targeting. ##### Parameters * `value`: The time, in Unix milliseconds, when LaunchDarkly should remove the context from individual targeting for this flag * `variationId`: ID of a variation on the flag * `contextKey`: The context key for the context to remove from individual targeting * `contextKind`: The kind of context represented by the `contextKey` Here's an example: ```json { "instructions": [{ "kind": "addExpiringTarget", "value": 1754006460000, "variationId": "4254742c-71ae-411f-a992-43b18a51afe0", "contextKey": "user-key-123abc", "contextKind": "user" }] } ``` #### updateExpiringTarget Updates the date and time that LaunchDarkly will remove the context from the flag's individual targeting ##### Parameters * `value`: The time, in Unix milliseconds, when LaunchDarkly should remove the context from individual targeting for this flag * `variationId`: ID of a variation on the flag * `contextKey`: The context key for the context to remove from individual targeting * `contextKind`: The kind of context represented by the `contextKey` * `version`: (Optional) The version of the expiring target to update. If included, update will fail if version doesn't match current version of the expiring target. Here's an example: ```json { "instructions": [{ "kind": "updateExpiringTarget", "value": 1754006460000, "variationId": "4254742c-71ae-411f-a992-43b18a51afe0", "contextKey": "user-key-123abc", "contextKind": "user" }] } ``` #### removeExpiringTarget Removes the scheduled removal of the context from the flag's individual targeting. The context will remain part of the flag's individual targeting until you explicitly remove it, or until you schedule another removal. ##### Parameters * `variationId`: ID of a variation on the flag * `contextKey`: The context key for the context to remove from individual targeting * `contextKind`: The kind of context represented by the `contextKey` Here's an example: ```json { "instructions": [{ "kind": "removeExpiringTarget", "variationId": "4254742c-71ae-411f-a992-43b18a51afe0", "contextKey": "user-key-123abc", "contextKind": "user" }] } ``` </details>

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/patchFlagsRequest"
      }
    }
  },
  "required": true
}

> ### Contexts are now available > > After you have upgraded your LaunchDarkly SDK to use contexts instead of users, you should use [Get expiring context targets for feature flag](https://apidocs.launchdarkly.com) instead of this endpoint. To learn more, read [Contexts](https://docs.launchdarkly.com/home/contexts). Get a list of user targets on a feature flag that are scheduled for removal.

> ### Contexts are now available > > After you have upgraded your LaunchDarkly SDK to use contexts instead of users, you should use [Update expiring context targets on feature flag](https://apidocs.launchdarkly.com) instead of this endpoint. To learn more, read [Contexts](https://docs.launchdarkly.com/home/contexts). Schedule a target for removal from individual targeting on a feature flag. The flag must already serve a variation to specific targets based on their key. You can add, update, or remove a scheduled removal date. You can only schedule a target for removal on a single variation per flag. Updating an expiring target uses the semantic patch format. To make a semantic patch request, you must append `domain-model=launchdarkly.semanticpatch` to your `Content-Type` header. To learn more, read [Updates using semantic patch](https://apidocs.launchdarkly.com). ### Instructions Semantic patch requests support the following `kind` instructions for updating expiring user targets. <details> <summary>Click to expand instructions for <strong>updating expiring user targets</strong></summary> #### addExpireUserTargetDate Adds a date and time that LaunchDarkly will remove the user from the flag's individual targeting. ##### Parameters * `value`: The time, in Unix milliseconds, when LaunchDarkly should remove the user from individual targeting for this flag * `variationId`: ID of a variation on the flag * `userKey`: The user key for the user to remove from individual targeting #### updateExpireUserTargetDate Updates the date and time that LaunchDarkly will remove the user from the flag's individual targeting. ##### Parameters * `value`: The time, in Unix milliseconds, when LaunchDarkly should remove the user from individual targeting for this flag * `variationId`: ID of a variation on the flag * `userKey`: The user key for the user to remove from individual targeting * `version`: (Optional) The version of the expiring user target to update. If included, update will fail if version doesn't match current version of the expiring user target. #### removeExpireUserTargetDate Removes the scheduled removal of the user from the flag's individual targeting. The user will remain part of the flag's individual targeting until you explicitly remove them, or until you schedule another removal. ##### Parameters * `variationId`: ID of a variation on the flag * `userKey`: The user key for the user to remove from individual targeting </details>

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/patchFlagsRequest"
      }
    }
  },
  "required": true
}

Returns the migration safety issues that are associated with the POSTed flag patch. The patch must use the semantic patch format for updating feature flags.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/flagSempatch"
      }
    }
  },
  "required": true
}

> ### Flag prerequisites is an Enterprise feature > > Flag prerequisites is available to customers on an Enterprise plan. To learn more, [read about our pricing](https://launchdarkly.com/pricing/). To upgrade your plan, [contact Sales](https://launchdarkly.com/contact-sales/). List dependent flags across all environments for the flag specified in the path parameters. A dependent flag is a flag that uses another flag as a prerequisite. To learn more, read [Flag prerequisites](https://docs.launchdarkly.com/home/targeting-flags/prerequisites).

> ### Flag prerequisites is an Enterprise feature > > Flag prerequisites is available to customers on an Enterprise plan. To learn more, [read about our pricing](https://launchdarkly.com/pricing/). To upgrade your plan, [contact Sales](https://launchdarkly.com/contact-sales/). List dependent flags across all environments for the flag specified in the path parameters. A dependent flag is a flag that uses another flag as a prerequisite. To learn more, read [Flag prerequisites](https://docs.launchdarkly.com/home/targeting-flags/prerequisites).

Get a list of all flag links.

Create a new flag link. Flag links let you reference external resources and associate them with your flags.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/flagLinkPost"
      },
      "example": {
        "key": "flag-link-key-123abc",
        "title": "Example link title",
        "deepLink": "https://example.com/archives/123123123",
        "description": "Example link description"
      }
    }
  },
  "required": true
}

Delete a flag link by ID or key.

Update a flag link. Updating a flag link uses a [JSON patch](https://datatracker.ietf.org/doc/html/rfc6902) representation of the desired changes. To learn more, read [Updates](https://apidocs.launchdarkly.com).

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/JSONPatch"
      },
      "example": [
        {
          "op": "replace",
          "path": "/title",
          "value": "Updated flag link title"
        }
      ]
    }
  },
  "required": true
}

Get a list of all flag triggers.

Create a new flag trigger.

{
  "content": {
    "application/json": {
      "schema": {
        "$ref": "#/components/schemas/triggerPost"
      }
    }
  },
  "required": true
}

Delete a flag trigger by ID.

Get a flag trigger by ID.