---
title: Versioning and deprecation
description: The API has one version, v100. Changes ship with the monthly release and are announced in its changelog entry; there is no fixed deprecation notice period.
canonical: https://developers.coevera.com/changelog/versioning-and-deprecation/
section: changelog
verification: behaviour
lastVerified: 2026-10-16
publisher: Coevera
---

# Versioning and deprecation

**Answer:** The Coevera API has one version, v100, in every URL, and no versioning by header. Changes ship with Coevera's monthly release and are announced in that release's changelog entry. There is no fixed notice period: anything marked Deprecated keeps working until a later release removes it, and a breaking change says what to do.

## One API version

`v100` is the API's only version. It appears in every REST and GraphQL URL, for example
`/api/v100/rest/spaces/{space_id}/entities/Accounts`, and no request header selects another
one. No other version number in the path reaches the API. There is no older or newer version to
move to: changes land in `v100`.

## How changes ship

Coevera releases every month, and maintenance releases can ship between them. Each change that
affects integrations is announced in the [API changelog](/changelog/api/) entry of the release
that ships it, with its type and the API it applies to:

- **Deprecated**: still works, and will be removed.
- **Removed**: no longer available.
- **Changed**: existing behaviour that now works differently, such as a status code or a
  validation rule.
- **Added**: something new that integrations can use, such as an entity, a field, a parameter or
  a webhook event.
- **Security**: a change made for security; the entry describes what an integration now gets.
- **Fixed**: a request that failed now works, or fails with a clear error.

A change that existing code may have to follow is marked **Breaking**, is listed first in its
release, and carries an **Action**: what the integration has to do.

## Deprecation

There is no fixed notice period. Anything marked **Deprecated** keeps working until a
**Removed** entry in a later release. Something that was never meant for integrations, or that
cannot keep working, can be removed without a deprecation period: its entry says so, and is marked
**Breaking**. A removal from the public GraphQL schema gets an entry too.

## Build for additions

Because changes land in the same version, write integrations that tolerate additions:

- ignore response fields you do not know;
- accept enum values and webhook events you have not seen before;
- do not depend on the order of fields in a response.

## What is not here

- MCP server versions have their own page: [MCP changelog](/ai/mcp-changelog/).
- Product features are in Coevera's
  [release notes](https://www.coevera.com/crm/release-notes/).
