Skip to main content
Verso ships changes to its own environments first and to production only after they have been exercised there. What you integrate against is covered by the rules below; anything not listed here may change without notice.

​
The API

GET /api/connections, GET /api/conversations, POST /api/purge and POST /api/ingest-export only change additively: new fields and new optional parameters appear, existing ones keep their name, type and meaning. A change that could break a client ships on a new versioned path kept beside the current one, with a deprecation period announced below before the old path is removed. Treat unknown fields as noise: ignore what you do not recognise rather than rejecting the response.

​
Webhooks

Payloads only grow. New event types may appear at any time: an endpoint that answers 2xx to events it does not handle keeps working. The signature scheme is fixed: X-Verso-Signature: t=<unix seconds>,v1=<hmac>; a new scheme would use a new prefix (v2=) and both would be sent during a transition. The claims of the link JWT (appId, userRef, scopes, purpose, jti, iat, exp) are stable; new claims are optional. Links live at most 15 minutes and are consumed on first use. The hosted pages and the native SDKs talk to the host your backend put in the link, so the same code works against any Verso environment you are given.

​
SDKs

@versoai/core, the iOS and Android SDKs, @versoai/react-native-connect and verso_connect follow semantic versioning: a breaking change is a major version, and published versions and tags are never moved or deleted. Pin a version and upgrade on your own schedule.

​
Deprecations

A deprecation is announced here and by email to your app’s contact address, with a removal date at least 90 days out; the old behaviour keeps working until then. Current deprecations: none.