LaunchDarkly package v1.0.0

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

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.

Risk classification: collection and single-resource reads sit at the minimum R0 tier; flag creation registers as create and deploy at the minimum R3 tier: 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 minimum R3 tier: 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 an extensive, deploy-equivalent write, and deploy is one of the designated actions requiring human approval.

Request limits: because the same endpoint and method also performs benign settings edits (name, description, tags, maintainer) and the request body is an unrestricted patch document, a lower-tier registration would not cover all effects of this endpoint — 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 minimum R3 tier 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.