Skip to content

Versions and updates

Published exact versions are immutable. Alias records have a short cache; changing an alias never overwrites the underlying version.

Environment vX.Y.Z git-<sha> / git-<sha>-run-<run-id> stable latest
Production chatbot.tiketo.cloud yes, immutable release no yes, manually promoted release yes, newest production deployment
Staging staging.chatbot.tiketo.cloud no yes, immutable commit build no yes, newest staging deployment

Use production stable as the default, a production vX.Y.Z to pin tested bytes, or staging latest for current verification. To find the immutable build currently behind staging latest, fetch its public manifest:

Terminal window
curl -fsS https://staging.chatbot.tiketo.cloud/embed/latest/manifest.json

Copy the manifest’s version value verbatim and replace latest in every embed URL—for example, /embed/<version>/loader.js. Do not reconstruct it from a commit SHA: staging versions are usually git-<sha>, but a manually re-run staging deploy publishes git-<sha>-run-<run-id>. The manifest also lists the SHA-256 digest of every published file. The alias and its manifest are short-cached, so record the resolved version with bug reports or test evidence. If the manifest is unavailable in an older environment, ask your Tiketo contact for the pin.

Since v0.3.0, a version manifest includes the generated tiketo-chat.d.ts beside the loader. v0.1.0 and v0.2.0 do not contain that file. Use the same exact version for loader and declarations; do not use /embed/stable/tiketo-chat.d.ts until stable is at least v0.3.0.

The on, off, and reset commands and locale-aware embed labels also require v0.3.0 or newer. On a pinned v0.2.0 loader these command-shaped calls can be misinterpreted as legacy initialization; other unknown commands on newer loaders produce a warning. Upgrade the loader before adopting the v0.3.0 API.

Review the changelog and Since vX.Y.Z notes before updating. Test with the staging ID/origin first, then bump the production loader and declaration together.

A new or changed client-specific action/component contract requires a new embed version because validation contracts are compiled into the loader. If your URL is pinned, bump it to the version Tiketo specifies; an older loader may ignore a new action or show component fallback.

  • v0.1.0: queue, initialization, launch context, and whereAmI.
  • v0.2.0: shared/host components, setFeature, one-shot replies.
  • v0.3.0: generated declarations, sticky on/off lifecycle events with stable error codes, logout-safe reset with optional relaunch, localized embed-owned UI, and explicit unknown-command handling.