Versioning and deprecation

Understand the API version, compatibility promises, deprecation notices, and upgrade workflow.

The REST API uses the stable /v1 base path. The OpenAPI document also carries a documentation release version—currently 1.3.0—so integrators can identify changes to the published contract.

Compatibility policy

Within /v1, ThriveDesk aims to make additive changes without breaking existing integrations. Examples include new optional request fields, new response fields, new endpoints, and new enum values where consumers are expected to tolerate unknown values.

A change is breaking when an existing valid request stops working or a documented response field is removed or changes type. Breaking REST changes require a new major URL version or an explicitly announced migration path.

Deprecation process

When a supported operation or field is scheduled for removal:

  1. The affected reference page and changelog identify the replacement.
  2. A removal date and migration window are published before enforcement.
  3. The old contract remains available during that window unless an urgent security issue prevents it.

No operation is currently marked deprecated in the public OpenAPI specification.

Consumer guidance

  • Ignore response fields you do not recognize.
  • Handle unknown enum values defensively.
  • Pin generated clients to a known version and review the changelog before regenerating.
  • Validate against the bundled OpenAPI specification in CI.