specification: API Commons Conformance specificationVersion: '0.1' provider: LaunchDarkly providerId: launchdarkly generated: '2026-08-27' method: searched source: >- Assertions checked against the live contract at https://app.launchdarkly.com/api/v2/openapi.json (401 operations), the RFC 8414 metadata at https://app.launchdarkly.com/.well-known/oauth-authorization-server, the RFC 9728 metadata at https://mcp.launchdarkly.com/.well-known/oauth-protected-resource/mcp/launchdarkly, the github.com/launchdarkly organization, and the published docs and pricing pages. note: >- Every row below is either backed by a location in a machine-readable document or is recorded as NOT conformant. No claim here rests on marketing copy. standards: - id: openapi name: OpenAPI Specification conforms: true version: 3.0.3 evidence: >- A complete, self-hosted, unauthenticated OpenAPI 3.0.3 document at https://app.launchdarkly.com/api/v2/openapi.json — 252 paths, 401 operations, 58 tags, HTTP 200, 2.97 MB. The provider links to it from its own docs and operates a getOpenAPISpec operation that returns it. - id: oauth2 name: OAuth 2.0 conforms: true evidence: >- RFC 6749 authorization_code, refresh_token and client_credentials grants declared in the provider's own RFC 8414 metadata document (HTTP 200), with a live authorization, token and revocation endpoint. - id: rfc8414 name: OAuth 2.0 Authorization Server Metadata conforms: true evidence: >- https://app.launchdarkly.com/.well-known/oauth-authorization-server returns 200 application/json with issuer, authorization_endpoint, token_endpoint, registration_endpoint, revocation_endpoint, response_types_supported, grant_types_supported, token_endpoint_auth_methods_supported, code_challenge_methods_supported and scopes_supported. Saved verbatim to well-known/launchdarkly-oauth-authorization-server.json. - id: rfc9728 name: OAuth 2.0 Protected Resource Metadata conforms: true evidence: >- An anonymous POST tools/list to the hosted MCP server returns 401 with 'WWW-Authenticate: Bearer resource_metadata="https://mcp.launchdarkly.com/.well-known/oauth-protected-resource/mcp/launchdarkly"', and that URL returns 200 with a valid resource/authorization_servers document. This is the correct RFC 9728 discovery chain, implemented end to end. - id: rfc7636 name: PKCE conforms: true evidence: 'code_challenge_methods_supported: ["S256"] in the authorization server metadata.' - id: rfc7591 name: OAuth 2.0 Dynamic Client Registration conforms: true evidence: >- registration_endpoint https://app.launchdarkly.com/trust/oauth/register/dcr in the RFC 8414 metadata. This is what lets an MCP client register itself without a human provisioning a client ID first. - id: oidc name: OpenID Connect conforms: false evidence: >- /.well-known/openid-configuration returns 404 on both launchdarkly.com and app.launchdarkly.com. LaunchDarkly is an OIDC/SAML relying party for customer SSO but is not an OpenID Provider. - id: rfc6902 name: JSON Patch conforms: true evidence: >- The provider documents JSON Patch as the default PATCH format inside the contract and cites RFC 6902 directly, including the `test` precondition operation. 50 references to JSON patch in the contract text. - id: rfc7386 name: JSON Merge Patch conforms: true evidence: Documented as a supported PATCH format in the contract's Updates section, citing RFC 7386. - id: rfc9457 name: Problem Details for HTTP APIs conforms: false evidence: >- Zero application/problem+json media types across 1,778 declared 4xx/5xx responses; all 1,778 are application/json carrying LaunchDarkly's own {code, message, id} envelope. See errors/launchdarkly-problem-types.yml. - id: rfc8594 name: Sunset and Deprecation HTTP headers conforms: false evidence: >- Zero occurrences of Sunset or Deprecation as header names in the contract, and no operation-level header parameters at all. Deprecation is signalled at design time (`deprecated: true` on 12 operations, plus a per-version EOL table) rather than at runtime on the wire. - id: pagination name: Consistent pagination conforms: true evidence: >- limit/offset parameters plus _links.first/last/next/prev on paginated collections, applied uniformly and versioned deliberately — the 20240415 version exists largely to convert previously-unpaginated list endpoints to this scheme. - id: idempotency name: Idempotency keys conforms: false evidence: >- Zero occurrences of "idempot" in the 401-operation contract; no idempotency-key header is declared or documented anywhere. JSON Patch `test` preconditions and atomic semantic patch are the nearest facilities and they are not the same thing. See the idempotency block in conventions/launchdarkly-conventions.yml. - id: rate-limit-headers name: Rate limit response headers conforms: true partial: true evidence: >- Nine documented headers across three limit families (global, route, access token) plus Retry-After for IP-based limits. These are the X-Ratelimit-* vendor forms, NOT the IETF draft RateLimit-Limit/Remaining/Reset headers, and the provider deliberately does not publish the numeric limits. - id: cors name: Cross-Origin Resource Sharing conforms: true evidence: 'Documented in the contract: Origin echoed or `*`, Access-Control-Max-Age 300, credentialed session calls supported.' - id: sse name: Server-Sent Events conforms: true evidence: >- The SDK streaming surface is SSE-based; LaunchDarkly maintains and publishes SSE client implementations as first-party packages (launchdarkly-eventsource on PyPI 1.7.2, github.com/launchdarkly/okhttp-eventsource for the JVM). Note this is the SDK delivery path, not the REST API. - id: scim name: SCIM 2.0 conforms: true partial: true evidence: >- LaunchDarkly is a SCIM SERVICE PROVIDER for user provisioning — the pricing page lists "SCIM user provisioning" as an Enterprise feature, and the contract itself encodes SCIM as a first-class state: an `isScim` boolean on authorized applications, and explicit behaviour changes ("Requests to create account members will not work if SCIM is enabled for the account", "Delete account member will not work if SCIM is enabled"). No /scim/v2 path and no urn:ietf:params:scim:schemas URN appear in the PUBLIC v2 contract, so the SCIM endpoint itself is not part of this API — it is configured through the IdP integration. Recorded as partial for that reason rather than claimed outright. - id: mcp name: Model Context Protocol conforms: true evidence: >- A first-party hosted MCP server at https://mcp.launchdarkly.com/mcp/launchdarkly speaking streamable HTTP (a GET returns the standard "this server uses POST-based Streamable HTTP transport" JSON-RPC notice), advertising 125 tools with MCP annotations (Read-only, Idempotent, Destructive, Open-world), plus a published stdio server on npm. OAuth-gated with correct RFC 9728 discovery. See mcp/launchdarkly-mcp.yml. - id: a2a name: A2A Agent Card conforms: false evidence: >- /.well-known/agent-card.json and the legacy /.well-known/agent.json both return 404 on launchdarkly.com and app.launchdarkly.com. apidocs.launchdarkly.com returns 200 for every path including these, but it serves the same 72,904-byte HTML redirect shell — a soft-404, not an agent card. No card is published. - id: llms-txt name: llms.txt conforms: true evidence: >- https://launchdarkly.com/docs/llms.txt returns 200 text/plain, 40,348 bytes, 974 lines of real llms.txt structure. It also documents two agent affordances beyond the format: appending .md to any docs URL returns clean Markdown, and it names an MCP endpoint for AI clients. Saved verbatim to llms/launchdarkly-llms.txt. - id: asyncapi name: AsyncAPI conforms: false evidence: >- No provider-published AsyncAPI document was found. LaunchDarkly documents a real webhook surface (payloads identical to audit log entries, HMAC-SHA256 signature verification) but ships no machine-readable event contract for it. The AsyncAPI in asyncapi/ is API Evangelist-generated from that documentation, not harvested. - id: json-schema name: JSON Schema conforms: true partial: true evidence: >- Schemas are expressed as OpenAPI 3.0.3 Schema Objects, which are a JSON Schema dialect subset rather than full 2020-12. No $schema declaration is present. domain_standard: market: feature management / feature flagging standard: id: openfeature name: OpenFeature body: Cloud Native Computing Foundation (CNCF) conforms: true evidence: >- LaunchDarkly publishes and maintains first-party OpenFeature PROVIDERS — the vendor-side half of the OpenFeature spec — across four runtimes in its own GitHub organization: launchdarkly/openfeature-java-server, launchdarkly/openfeature-python-server, launchdarkly/openfeature-dotnet-server and launchdarkly/openfeature-ruby-server, each with a matching hello-openfeature-* example repo. The Node provider ships to npm as @launchdarkly/openfeature-node-server 1.4.0 (published 2026-08-25) and the JVM provider to Maven Central as com.launchdarkly:launchdarkly-openfeature-serverprovider 1.1.1 (2025-04-15). location: >- SDK layer, not the wire contract. The OpenFeature evaluation API is a client-side abstraction, so conformance is verifiable in the published provider packages and repositories rather than as a signature inside the OpenAPI document — there is no OpenFeature URN or media type to look for in a REST contract. Recorded with that distinction stated rather than blurred. buyer_impact: >- A team that has standardised on OpenFeature can adopt LaunchDarkly without writing a bespoke connector, and can leave without rewriting evaluation calls. For a category whose central switching cost is exactly that rewrite, a vendor shipping and maintaining its own OpenFeature provider is a substantive, checkable commitment rather than a logo on a page. note: >- No regulatory regime in scoring.yml covers developer tooling / feature management, so there is no regime standards[] shortlist to cross-check for this provider. OpenFeature is recorded because it is genuinely the category's standard and LaunchDarkly genuinely implements it — not to fill a slot. compliance: published: true source: https://launchdarkly.com/security/ trust_center: https://trust.launchdarkly.com/ trust_center_platform: Vanta certifications: [SOC 2, ISO 27001, HIPAA, FedRAMP, GDPR] see: security/launchdarkly-trust-center.yml data_residency: - region: United States (commercial) base: https://app.launchdarkly.com - region: United States federal base: https://app.launchdarkly.us note: FedRAMP instance; the hosted MCP server is not available here. - region: European Union base: https://app.eu.launchdarkly.com note: EU data residency, including for AgentControl as of 2026-08-26. summary: asserted: 22 conformant: 16 non_conformant: 5 partial: 4 headline: >- Strong on the identity and agent side — OAuth 2.0 with DCR and PKCE, correct RFC 8414 and RFC 9728 discovery, a live MCP server, a real llms.txt — and deliberately non-standard on the HTTP-semantics side: no RFC 9457 problem details, no RFC 8594 sunset headers, no idempotency keys, and vendor X-Ratelimit-* rather than the IETF RateLimit-* headers.