# Versioning

> How the HubFit API changes: what can ship in v1 without notice, what makes a new version, and how deprecations are announced.

Source: https://hubfit.com/developers/versioning

## API versions

The version is in the path: `/v1`. Breaking changes ship as a new major version path (`/v2`) alongside this one, so your integration keeps working until you move.

**Current version**

```text
https://api.hubfit.com/v1
```

## Changes that can ship in v1

These aren't breaking and can ship in this version at any time, so write your integration to take them in stride:

- New endpoints, new optional parameters and new response fields: ignore fields you don't recognise.
- New enum values in responses, and new error `code`s: treat a value you don't recognise as "other". The reference marks these lists **Known values**.
- New `include` sections on [client summaries](https://hubfit.com/developers/api/client-summaries).
- Cursors of a new length or format: don't parse them. An id stays a 24-character hex string.
- New webhook event types and new fields on events. An event type's name and its existing fields never change: a breaking change ships as a new event type.

## Deprecations

A deprecated field, parameter or version keeps working for at least 6 months after we announce it. From then on its responses carry `Deprecation` and `Sunset` headers ([RFC 9745](https://www.rfc-editor.org/rfc/rfc9745), [RFC 8594](https://www.rfc-editor.org/rfc/rfc8594)), and the [changelog](https://hubfit.com/changelog) lists it.