Developers
ChangelogSupportcoevera.comGet API keys
Set your API contextPick a region and space ID once. Every sample fills in your base URL.
Where do I find these?

In Coevera: open your space's API application and choose Show Access. It shows the space ID and the base URL, whose host starts with your region.

From the API: if you know the space ID, the discovery endpoint GET /api/discovery/spaces/{space_id} returns its region and base URLs, without credentials.

Only the region and space ID are kept, in this browser. Never paste a key or password here.

More in the quickstart

ChangelogVersioning and deprecation

Versioning and deprecation

View as Markdown/changelog/versioning-and-deprecation.mdOpen in ClaudeAsk Claude about this pageOpen in ChatGPTAsk ChatGPT about this page

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.

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 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

Verified on 2026-10-16 against API 6.5Behaviour-verified

Every sample on this page ran against the docs sandbox and returned the response shown.