Versioning
The /v1 prefix identifies the HTTP namespace. It is separate from the API service release and the semantic versions of the SDK packages.
Current Compatibility Expectations
XKOVA is in pre-launch alpha. Request and response shapes, validation, identifiers, and behavior may
change in place under /v1. Earlier alpha contracts do not have a compatibility overlap.
Update your integration against the current API Reference and keep
SDK packages aligned with the environment you use.
Removing an implementation must not silently remove a supported product capability. Immutable on-chain deployments and third-party provider contracts have their own versioning constraints.
The Version Dimensions
| Identity | What it identifies |
|---|---|
/v1 | The HTTP API namespace. |
| API service version | The reviewed API component release. |
| SDK package version | A release of @xkova/sdk or @xkova/browser. |
| Exact build | The source revision and immutable artifacts deployed to an environment. |
| Contract deployment | The chain, address, and deployed bytecode provenance. |
See Changelog for current component versions. The SDKs already have semantic versions and are available as alpha packages.
Writing Clients That Tolerate Additions
Ignore response fields your application does not use. Handle documented status values and errors explicitly, and retain a correlation ID when reporting a failure. An added optional field can be safe for a tolerant client; a removed field, changed type, or tighter validation may require code changes.
Review Deprecations before assuming a notice period or
Sunset header protects an earlier alpha integration.