Skip to content

⚠️ Recent Visits is in beta. All listings and data shown are for demonstration purposes only and do not represent real or verified information. Tour listings are based on content from partner agencies’ websites and have not yet been confirmed by the agencies.

Recent Visits

SDK versioning

The widget's current version, how compatibility works within API version 1, how to upgrade, and what does not exist yet (changelog, published package).

On this page

What exists today#

ItemCurrent state
API versionv1, served at https://recent-visit.com/api/widget/v1.
Script addresshttps://recent-visit.com/widget/1/widget.js. The 1 is the API major version, not the package version.
Package@recent-visits/widget, version 0.1.0, ready to publish but not published to npm yet.
Changelog / release notesNone yet.

Compatibility promise within version 1#

  • The widget uses API v1. Within version 1 the service only adds optional fields and new error codes; the widget ignores fields it does not know.
  • A breaking change would ship as API v2 with a new script address (/widget/2/widget.js). v1 would keep working for a published sunset period.
  • Pin the major version: use the /widget/1/ address (and, once the package is published, a ^1 range).

Upgrading#

  • Script tag: nothing to do. The address is stable, and the file behind it is updated with bug fixes and improvements. If you use Subresource Integrity, update the integrity hash from /widget/1/widget.js.integrity.txt whenever you want the new file; otherwise the browser will refuse the changed script (which is the point of integrity).
  • Package (future): upgrade within the same major version and re-run your tests. Because the package bundles the interface into your app, it changes only when you upgrade it.

After any upgrade, open your Test site and check the chat, the tours list and a test quote request.

Gaps and a recommendation#

There is no published release history, so you cannot yet tell what changed between two versions of the file. A lightweight approach that fits the project: keep a CHANGELOG.md in the SDK package with a short entry per release (added, changed, fixed, and any behaviour that affects embedders), publish the package with semantic versioning, and note the package version in the script's header comment. Until that exists, treat any change as non-breaking within v1 and test on the Test environment first.

Last checked against the product:

Related articles

  • SDK API reference · The public surface of the Recent Visits widget package: init, the widget handle, the headless client, errors, types and the HTTP endpoints they use.
  • SDK installation · Install the Recent Visits widget with a script tag, add Subresource Integrity, run it locally, and understand the current npm status.

Still stuck? Contact us and tell us what you tried.