--- title: Versioning description: Discover the cluster version and handle compatible API additions. doc_version: 0.1.0-preview last_updated: 2026-09-14 --- # Versioning Each cluster serves one major API version. Select the cluster by base URL and discover its current capabilities with Info. ## Discover the version **GET https://engine.example.com/info** ```http GET /info HTTP/1.1 Host: engine.example.com Authorization: Bearer ``` Read the `api_version` string in the response. Routes have no version prefix. Use the configured base URL for every operation on that cluster. The same response lists the Search modes in `search.modes`, the Answer efforts in `answer.efforts`, URI schemes, and event types. Capabilities can differ between clusters. Check them before you use a mode or an effort in your application. ## Compatible additions Within a major version, releases can add routes, optional request fields, response fields, and response enum values. Ignore response fields you do not use. Handle unknown status values without treating them as a known terminal state. Send only request fields that the running release supports. Unknown request fields return `400 invalid_request`. A newer documentation page does not make an unavailable capability valid on your cluster. ## Major version boundaries Breaking changes require a new major version on a new cluster. A cluster’s existing major API contract remains stable. Your application selects the target through its base URL. Use the [published OpenAPI document](/engine/openapi.json) to inspect request and response schemas. Use [Info](/engine/reference/info) to confirm the actual cluster’s version and modes. The [Engine changelog](/engine/changelog) lists each release that changes what a client or an operator does. ## Sitemap See the full [sitemap](/sitemap.md) for all pages.