Versioning & stability

What the /v1 prefix guarantees, how the API evolves without breaking you, and where your tenant's exact surface is defined.

Every path is served under /v1. That prefix is your stability contract: within it, the API only grows in compatible ways.

What stays stable

Within /v1, changes are additive. We may:

  • add new capabilities, endpoints, and optional request fields;
  • add new fields to responses.

We won't remove a field, rename one, or change its type under /v1 without versioning the change. Treat unknown response fields leniently — new ones can appear — and never depend on field order.

Your tenant's surface is the source of truth

The set of endpoints you can call depends on which Apps are installed in your tenant. The authoritative, always-current description of your surface is the OpenAPI document the gateway serves — explore it interactively in the API Explorer:

Your tenant's OpenAPI
curl https://api.revenexx.com/v1/openapi.json \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>" \
  -H "X-Revenexx-Api-Key: rvxk_..."

Generate typed clients from it with the CLI (revenexx types / revenexx generate) so your code tracks the contract.

How changes reach you

Breaking changes and deprecations — when they ever become necessary — are announced ahead of time on the Changelog, with a migration path. There is no dated-version selector today: there is one current version, /v1, and it evolves additively.

Pin your integration to behavior, not to incidental details. Read the fields you need, ignore the rest, and regenerate your types when you adopt something new.
Was this page helpful?