Versioning and changelog

The version is part of the URL (/v1). Within a version we only make backwards-compatible changes; breaking changes go into a new version.

Versioning policy

Compatible (may ship in v1 without prior notice; your integration must tolerate them):

New endpoints, optional parameters or response fields.
New error codes (with a consistent HTTP status) and new webhook events (you only receive them if you subscribe).
Changes to the error message text.
New values of enumerations documented as extensible.

Breaking (only in a new version): removing or renaming fields, endpoints or events, changing types or making a parameter required. When a new version ships, the previous one keeps working for a transition period announced in advance to the administrators of the companies using it.

Ignore unknown fields when reading JSON (no strict deserialization) and don't rely on key order.

Status

Version	Status	Content
`v1`	Stable	Areas, employees (incl. import), vacations, time entries, template messages, verification codes (Verify) and webhooks.
`v2`	Planned	Contracts (with signed document; `contract.signed` and `contract.expiring` events). It currently shows as unavailable in the panel.

Changelog

v1 — Template buttons and review (November 2026)

Templates can have up to 3 buttons: quick reply (quick_reply, with a payload returned in the webhook) and link (url, max. 2, with an optional variable filled with the new button_variables field of POST /messages). See Templates and buttons.
Button texts are per language (texts, same shape as languages, one per template language) and each message shows them in the language of its text.
New webhook message.button_clicked (first tap of each button; with the button text in the language sent and its language).
Template object: new fields buttons, version and review_flags; new status superseded (editing an approved template creates a new version). New errors 409 template_paused and 422 invalid_button_variables.
Template texts can no longer contain links (http(s)://, www.): use link buttons. Templates already approved keep working.
POST /verify/check keeps working even if the limits cannot be checked at that moment (it no longer returns 503 limits_unavailable).

v1 — Verify (November 2026)

verify product: POST /verify/start (with a required Idempotency-Key), POST /verify/check and GET /verify/{id}. 6-digit codes through the xYago chat, with an immediate 404 recipient_not_on_xyago for your SMS fallback. See Verify.
Webhooks verification.delivered, verification.read, verification.verified, verification.expired and verification.failed.
The planned otp product (v2, /otp/send and /otp/verify, never released) is retired: verify replaces it.

v1 — messages (November 2026)

messages product: POST /messages (with a required Idempotency-Key), GET /messages, GET /messages/{id}, GET /senders and GET /templates. See Messages and Inviting users.
Webhooks message.sent, message.delivered, message.read, message.failed, sender.status_changed and template.status_changed.

v1 — initial release

areas, employees, vacations and time_entries products with live and sandbox API keys, scopes, IP allowlist and rate limit configurable in the panel.
Asynchronous employee import with upsert by external_id.
Signed webhooks (HMAC-SHA256) with retries and zero-downtime secret rotation.