launchdarkly v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-launchdarkly-service-token

Custody

customer_vault

Injection

header (Authorization)

A LaunchDarkly SERVICE access token, held in the client's own secret manager. Token issuance is external: a team member with sufficient permissions creates the token on LaunchDarkly's Authorization page (or an integration admin provisions it), and the deployment's custody job stores it under this reference. Stored-value format, stated exactly because it is unusual: the Authorization header value IS the raw access token with NO scheme — LaunchDarkly's documentation states the value of the Authorization header must be the access token itself, so the stored material is the bare token string and the injector sends it verbatim. Prefer a service token over a personal token: service tokens are account-level and are not tied to one member's continued employment. Expiry and revocation behavior, stated honestly: LaunchDarkly access tokens do not carry an automatic TTL — a token remains valid until it is reset (rotated) or deleted on the Authorization page, so rotation cadence is the custody job's responsibility and a leaked value must be reset explicitly; resetting or deleting invalidates the value immediately and it fails closed. Note the gap: changing the role attached to a token narrows its future authorization decisions, and disabling the creating MEMBER does not invalidate a SERVICE token they created — revocation is per-token. Each token is pinned to an API version at creation; confirm the pinned version serves the registered /api/v2 paths (or send LD-API-Version per request — the pinned-token approach is the default this pack assumes). Least privilege: attach a custom role granting only the actions the enabled capabilities need, scoped to the specific projects and environments this pack is bound to — in particular, grant flag-targeting write actions on production environments ONLY where the R3 update capability is intentionally enabled, since the same role gates the deploy-equivalent toggle. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• launchdarkly-account (api, internal): https://launchdarkly-api.invalid/api/v2

The endpoint host 'launchdarkly-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's LaunchDarkly base URI before enabling — app.launchdarkly.com for commercial, app.eu.launchdarkly.com for the EU instance, app.launchdarkly.us for federal — in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so all three move together, and substitution is a required deployment step. PROJECT_KEY and FLAG_KEY in the endpoint paths are placeholders to bind before enabling. Tiering rationale, and the central design decision of this pack: collection and single-resource reads sit at the R0 floor; flag creation registers as create AND deploy at the R3 floor: creation is not guaranteed inert, because a newly existing flag's OFF variation can differ from the application's missing-flag fallback value, so creating a flag can change served behavior before any toggle or targeting. The flag UPDATE endpoint (PATCH /api/v2/flags/{project}/{flag}) is registered once, as update and deploy at the R3 floor: the endpoint accepts JSON patch, JSON merge patch and semantic patch bodies, and a semantic patch instruction such as turnFlagOn or turnFlagOff, addTargets or updateFallthroughVariationOrRollout changes what production software serves to end users immediately — toggling a feature flag in a production environment is a high-blast-radius, deploy-equivalent write, and deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Effect-level honesty: because the SAME endpoint and method also performs benign settings edits (name, description, tags, maintainer) and the request body is an unrestricted patch document, no lower-tier registration of this endpoint is honest — an installer's intention to patch only settings is not a restriction the registration enforces, so this pack registers the endpoint once at R3 and does not offer a separate 'settings-only' capability. Flag deletion and project deletion sit at the R3 floor as deletes. Provider-side controls, noted but not relied on: LaunchDarkly can require approvals for flag changes in an environment, in which case a direct API change fails with 405 and must go through an approval request — that is the provider's control, not this registration's, and this pack deliberately does NOT register the approvals API (creating or applying approval requests is approve-equivalent and needs its own review). API versioning: each access token is pinned to an API version at creation (tokens created before versioning are pinned to 20160426), and a request may override with the LD-API-Version header; this pack registers paths under /api/v2 and the deployment should confirm the token's pinned version serves them. Documented exclusions: this pack does not register the access tokens API (token lifecycle is an external custody process — see the credential note), members/teams/custom-roles management (access-granting), the approvals API, segments management, environment creation/deletion, data export, relay proxy configuration, and webhooks/integrations. SDK keys, mobile keys and client-side IDs cannot call this REST API at all — a deployment must not store one under this pack's reference.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://launchdarkly.com/docs/api (retrieved 2026-09-21)
• https://launchdarkly.com/docs/api/feature-flags (retrieved 2026-09-21)
• https://launchdarkly.com/docs/api/feature-flags/patch-feature-flag (retrieved 2026-09-21)
• https://launchdarkly.com/docs/api/access-tokens (retrieved 2026-09-21)
• https://launchdarkly.com/docs/api/feature-flags/post-feature-flag (retrieved 2026-09-21)
• https://launchdarkly.com/docs/api/projects/delete-project (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.