Versioning Policy
This document outlines how enza manages versioning for the TX API and its documentation.
API Version
The public API version is defined in the URL path. This ensures clear separation between different API generations and prevents breaking changes from affecting existing integrations.
| Version | URL Path | Status |
|---|---|---|
| v2 | /TX/v2 | Current |
| v1 | /TX/v1 | Supported (legacy) |
When We Create a New API Version
A new major version (e.g., /TX/v2) is created only for breaking changes such as:
- Removing or renaming endpoints
- Changing request/response structures
- Modifying authentication requirements
- Altering core business logic behavior
We maintain older API versions for a reasonable deprecation period to ensure you have time to migrate.
Documentation Version
The OpenAPI specification uses Semantic Versioning (MAJOR.MINOR.PATCH):
| Version Change | Description | Example |
|---|---|---|
Patch 1.0.0 → 1.0.1 | Bug fixes, typo corrections, clarifications | 1.0.1 |
Minor 1.0.0 → 1.1.0 | New endpoints, non-breaking additions | 1.1.0 |
Major 1.0.0 → 2.0.0 | Breaking documentation changes, new API version line | 2.0.0 |
Changelog
Every documentation and API release is recorded in the Changelog. We use the following format:
v1.0.0— Major documentation releasesv1.0.1— Patch releasesv1.1.0— Minor releases with new featuresv2.0.0— New API version line
Support Policy
| API Version | Support Status | Notes |
|---|---|---|
| v2 | Active | Current stable version |
| v1 | Supported | Maintained for existing integrations; migrate to v2 |
For questions about versioning or migration, contact your assigned Product Manager or our support team.
Last modified on