LaunchDarkly publishes 30 API pages on the network. The smallest one carries the most risk. The Flag Triggers API exists to “create triggers that allow external services to toggle feature flags via unique webhook URLs.” It returns a URL, and anyone who holds that URL can switch a production flag on or off. The design is good. Our record of it is incomplete, and the fault is ours.
What the page shows
Both operations use one path, /flags/{projectKey}/{flagKey}/triggers/{environmentKey}, on https://app.launchdarkly.com/api/v2, behind a bearer token. listFlagTriggers returns the triggers set on a flag in one environment. createFlagTrigger takes instructions whose kind is limited to turnFlagOn or turnFlagOff, and returns a triggerUrl.
The enum is the right call. A trigger cannot rewrite targeting, change percentages or swap variations. It is a kill switch, which is exactly what an APM alert or a CI job should be allowed to operate without broad API access.
What the page leaves out
If this page were the whole contract, it would describe a credential that can be minted but never revoked. It is not the whole contract. LaunchDarkly’s own REST API definition, which we hold and have set aside as superseded, describes the lifecycle in full:
| Operation | In LaunchDarkly’s contract | On the apis.io page |
|---|---|---|
| List flag triggers | yes | yes |
| Create flag trigger | yes | yes |
| Get flag trigger by ID | yes | no |
| Update flag trigger | yes | no |
| Delete flag trigger | yes | no |
The update operation is where the security model lives. It takes semantic-patch instructions. cycleTriggerUrl “generates a new URL for this trigger”, which is rotation for a leaked secret. disableTrigger stops the trigger without deleting it, and replaceTriggerActionInstructions changes what it does. LaunchDarkly treated the URL as a credential and documented how to rotate it. Our split of the contract dropped that part.
The gap is not limited to this API. LaunchDarkly describes its REST API as 401 operations, and the superseded definition does count 401. The 30 pages we publish add up to 69 operations. The pages were split from a shorter, authored copy of the contract rather than from LaunchDarkly’s own. That is the catalog’s defect, and we are logging it as one.
The provider around it
LaunchDarkly scores 80.8, exemplar, with operational transparency at 92.1 and access clarity at 100.0. Its MCP server and its protected resource metadata are both verified, and dynamic client registration is lit. The weakest facet is contract governance at 31.8. Some of that weakness is likely an artifact of the thin contracts described above, so read the facet with that in mind until the contracts are rebuilt. Agent Readiness is 51.9. That score would reach agent-native, but the band is gated to agent-ready because idempotency is unlit, and a retried POST that mints a second live trigger URL is the kind of error an idempotency key prevents.
What would move it
The first fix is ours: rebuild the 30 pages from LaunchDarkly’s full definition so the trigger lifecycle, and the other operations lost in the split, appear where integrators and agents look for them. The fix that belongs to LaunchDarkly is a documented idempotency key on creation, which would clear the gate. Neither fix requires redesigning the API.
See the API at apis.io/apis/launchdarkly/launchdarkly-flag-triggers-api/ and LaunchDarkly’s reference at launchdarkly.com/docs/api.