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 event type values in the event catalog.

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.

There is no version pinning — no version request header, no per-key version setting, no test/live split. Every caller is on the same version of the API at the same instant, which is why the additive rule above does most of the work.

The object field is your anchor

Every resource carries a stable object field (template, ontology, passport, import, file, composition, 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"
  // ...
}