Skip to main content
hubfit
Start for freeOpen HubFit

Concepts

Versioning

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

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
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 codes: treat a value you don't recognise as "other". The reference marks these lists Known values.
  • New include sections on 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, RFC 8594), and the changelog lists it.