Versioning
Kheelona Voice has two versioned surfaces. Both are at version 1.
| Surface | Version | Where you see it |
|---|---|---|
| The REST API | v1 |
The path: /v1/sessions. |
| The realtime protocol | kheelona.v1 |
The WebSocket subprotocol: kheelona.v1. |
What is not a breaking change
Section titled “What is not a breaking change”Kheelona may add these at any time, without a new version:
- new endpoints, and new optional request fields;
- new fields in responses and in realtime events;
- new event types;
- new error codes;
- new voices, languages and options.
Your client must ignore what it does not know: unknown fields, unknown event types and unknown error codes. Treat an
unknown error code by its HTTP status and its fatal flag. The other direction is strict: POST /v1/sessions refuses
fields it does not know, so send only documented fields. See Errors and retries.
What is a breaking change
Section titled “What is a breaking change”Removing or renaming anything, or changing what something means, is a breaking change. It only ever ships as a new
version: v2 for the API, kheelona.v2 for the protocol.
How long the old version lasts
Section titled “How long the old version lasts”When a new version arrives, both versions are supported side by side for at least six months. The changelog announces it.
The browser SDK
Section titled “The browser SDK”The browser SDK has its own version number, in the file name of the package you received (kheelona-voice-<version>.tgz). It follows semantic versioning. See the browser SDK guide.