Skip to main content

Versioning and changelog

Versioning​

The version is part of the path: every endpoint is under /v1.

Within a version, changes are additive only. We may, without a new version:

  • add new endpoints
  • add new fields to responses
  • add new optional request parameters and fields
  • add new event types and new values to reference lists
  • add new error code values

We will not, within v1:

  • remove or rename an endpoint, a field or a parameter
  • change a field's type or meaning
  • make an optional parameter required
  • change the shape of errors, pagination or webhook payloads

So that additive changes never break your integration:

  • Ignore fields you do not recognise rather than failing on them.
  • Handle unknown enum values (a new vehicle status, a new event type) gracefully, for example by logging and skipping.
  • Subscribe webhooks to named event types and ignore any type your code does not handle.
  • Branch on error code, and have a default for codes you do not know.

A breaking change would ship as a new version (/v2) alongside v1, with notice and time to migrate.

Changelog​

2026-09-27 - v1 released​

The first public version of the Vehiso API:

  • REST endpoints for vehicles and images, branches, enquiries, customers, deals, invoices, payments, appointments, workshop job cards, part exchanges, users and reference lists.
  • Secret, publishable and test keys, managed in the DMS under Administration > Developers.
  • Batch stock upload with images by URL.
  • Website themes: request builds from the AI theme builder and publish theme versions.
  • Webhooks with signed deliveries, and the /v1/events log.
  • OAuth 2.0 with PKCE for partner apps.
  • MCP server at /v1/mcp, including website theme tools.