API Versioning

Versioning Principles

SECUTIX public web services and webhooks are versioned.

The active version is always the one with the highest version number.

The public documentation always refers to the active version. YAML specification files for previous versions remain available for download.

Versions follow this pattern:

major_minor

If the minor version is not provided, it is implicitly 0.

Examples:

• s360/v3/contacts → contacts resource, major 3, minor 0
• s360/v3_3/catalog → catalog resource, major 3, minor 3

Version evolution may differ per system. (See Understanding Endpoint URLs)

---

Version Changes

1. Minor, backward-compatible improvements may be applied to the active version without creating a new version.
2. Non backward-compatible changes (see definition below) require a new version with the minor number increased.
3. Major redesigns or structural refactoring require a new version with the major number increased.

---

Backward Compatibility

The following changes are considered backward compatible and should already be handled by integrators during implementation:

• Adding new fields (optional fields in response objects)
• Adding new endpoints (new capabilities without modifying existing ones)
• Extending enums (adding new possible values)
• Performance or stability improvements (without modifying data structures)

Any other type of change is considered non-backward compatible, including:

• Removing an endpoint
• Renaming a field in a schema
• Removing a field in a schema
• Adding a mandatory parameter to an endpoint