An exposure records that a target saw a control-point value. fw-server still accepts capture batches on POST /v1/capture with type: "exposure". That wire path is unchanged.
The SDK exposures namespace (record, flush) and the per-call sendExposure opt-in were removed from the v1 client surface (ADR-0010). A v1 read is side-effect free: no read emits telemetry as a consequence of being called (spec/control-points.md). See Migrate 2.1 to 2.3. Why the concept still matters
Evaluation says what value was chosen. An exposure is the separate claim “we showed this variant.” Those are different facts. Keeping them separate is why a read must not imply assignment.
The console and analytics pipelines can still join on targetingKey + flagKey. That join is a platform concern. The SDK does not queue, dedup, or flush exposures for you.
This is not OpenFeature Tracking (spec §6). The bundled OpenFeature provider is gone; track was never implemented.
How it relates
What replaced the client API
Nothing on the client. If your 2.1 code called exposures.record / flush, or passed sendExposure: true, delete those calls. Do not expect client.shutdown() to drain an exposure queue you can no longer write to.
The test-server stub still implements POST /v1/capture because the wire path exists. That is not an SDK exposures API.
Last modified on September 11, 2026
