Skip to main content
The Oviond REST API is versioned in the URL path. Every endpoint today lives under /v1:

​
What we may change without a new version

These are additive and can ship at any time — build your integration to tolerate them:
  • New endpoints.
  • New optional request fields.
  • New fields in a response object.
  • New values in an enum where the field is already documented as extensible.
Parse responses tolerantly — ignore fields you don’t recognize, and don’t fail on new properties. A strict client that rejects unknown fields will break on additive changes.

​
What counts as a breaking change

Breaking changes ship under a new version prefix (for example a future /v2), and /v1 continues to work during any migration window:
  • Removing or renaming an endpoint, field, or enum value.
  • Making a previously optional request field required.
  • Changing a field’s type or the shape of the response envelope.
  • Changing authentication or default behavior in a way that rejects previously valid requests.

​
Staying current

  • Follow the Changelog for additive changes and deprecations.
  • Field names are always snake_case; timestamps are ISO 8601.
  • Pin your integration to /v1 explicitly — never depend on an unversioned base URL.