Skip to content

API Stability and Versioning

Before building on the RealityConnect API long-term, understand which parts of the surface are stable, how experimental operations are marked, and what to expect across upgrades.


Some operations in the API reference carry an experimental stability marker. Look for x-scalar-stability: experimental on an operation in the OpenAPI document (visible as a stability badge in the rendered API reference) to identify them. This is kept in sync with the API automatically, so check there rather than relying on a fixed list here.

Experimental operations are real and callable (not disabled or preview-only), but their paths, parameters, payloads, responses, or availability may change without the same stability guarantees as the rest of the API. See Getting Started: Experimental endpoints for how to work with them.

When an experimental operation stabilizes, that’s called out in the Release Notes.

ChangeBreaking?Why
New optional request parameterNoExisting requests keep working unchanged
New response fieldNoExisting consumers that read known fields are unaffected; parse responses tolerantly and ignore unrecognized fields
New enum value added to an existing fieldNoTreat enum fields as open sets and handle unrecognized values gracefully, rather than exhaustively matching every known value
Existing field removed or renamedYesBreaks any consumer reading that field
Existing field’s type or meaning changedYesBreaks any consumer relying on the previous shape
Required parameter added to an existing operationYesBreaks existing requests that don’t send it
Endpoint path or HTTP method changedYesBreaks existing requests outright
An experimental operation’s contract changesNo (by design)Experimental operations are explicitly exempt from the stability contract; see above
  • See the API reference for the current stability marker, request and response schema per operation.
  • See Getting Started for the security model and how to choose an OAuth flow.