Versioning

The API version is part of the URL: https://api.synexcloud.com/v1/.... Within v1, every change is additive and backwards-compatible, so an integration you build today keeps working as the platform grows. Breaking changes only ever ship under a new version prefix.

What can change within v1

Treat these as expected, non-breaking evolution — your integration must tolerate them:

• New endpoints and new optional request parameters.
• New fields on existing response objects.
• New values for fields documented as open-ended — for example, new action values in audit events.

What counts as breaking

Removing or renaming fields, changing a field's type or semantics, or tightening validation are breaking changes. They only ship as a new version prefix (/v2), and v1 keeps running through a deprecation window announced in advance.

The object field is your anchor

Every resource carries a stable object field (template, ontology, passport, import, file, composition, audit_event, list, and so on). It never changes for a given resource, so it's safe to switch on when you need to handle mixed results — for instance, distinguishing a list envelope from a single resource.

{
  "object": "passport",
  "id": "pass_00a1b2c3d4e5f607"
  // ...
}