API Versioning & Changelog
ChainIT APIs are built with long-term integration stability in mind. All versioning decisions are made to minimize disruption to production integrations while allowing the platform to evolve with new capabilities and improvements.
API Version Policy
ChainIT follows semantic versioning principles for its public APIs.
The current production release, API v1, represents a stable, fully supported interface. Improvements that do not introduce breaking changes are shipped within the same version and do not require client updates. These include:
- New optional request fields
- Additional response fields
- New query parameters
- Performance improvements
- Documentation updates
Breaking Changes
Breaking changes are never introduced within an existing major version. Examples include:
- Renamed or removed fields
- Endpoint removal
- Modified response schema
- Changes to required parameters
- Authentication flow changes
Such changes are deferred to a new major version (e.g., v2), which is released with an announced transition period.
Version Lifecycle
Each API version progresses through defined lifecycle stages to allow integration teams to plan migrations safely.
| Stage | Description |
|---|---|
| Active | Fully supported, receives all new features, and is recommended for new integrations. |
| Maintenance | Receives critical fixes and security updates but no new features. |
| Deprecated | Sunset date announced. Integrations must migrate before the deadline. Migration guides are provided. |
| Sunset | Version is no longer available. Requests return an error directing clients to a supported version. |
Changelog
The ChainIT changelog is published regularly and documents all platform updates.
Entries are structured to help developers quickly determine relevance and required action.
Entry Classification
Each changelog post begins with Tags indicating affected product areas, such as:
- Authentication
- Accounts
- Transactions
- Webhooks
- KYC
- KYB
- Pactvera
Entries are divided into:
Highlights
Significant updates introducing new capabilities or requiring developer action. Highlights typically include:
- Migration steps
- Documentation links
- Effective dates
Updates and Fixes
Minor improvements such as:
- Performance optimizations
- Bug fixes
- Documentation corrections
These usually require no integration changes.
Changelog Entry Structure
Each changelog entry contains the following information:
| Field | Description |
|---|---|
| Title | Concise description of the change. |
| Description | Explanation of what changed and why. |
| Affected APIs | Endpoints or parameters impacted. |
| Migration Guide Link | Link to migration instructions if applicable. |
| Effective Date | Date the change went live in environments. |
Version Upgrade Policy
When a new major version is released, ChainIT ensures integrations are not disrupted without notice:
- Previous versions remain active for a defined transition period.
- Migration documentation is provided.
- SDK updates are released alongside new versions.
- Engineering and support teams assist during migration.
- Deprecation warnings appear in API response headers for features scheduled for removal.
Backward Compatibility Commitment
Within a single major API version, ChainIT guarantees:
- Existing fields will not be removed or renamed.
- Required parameters will not become stricter.
- HTTP status and error structures remain stable.
- New optional fields may be added at any time.
- New optional parameters may be added without version bumps.
Important Note
Client integrations should implement tolerant reader patterns, meaning:
- Ignore unknown response fields.
- Avoid failing on additional properties.
- Support additive API evolution without requiring client updates.
This ensures integrations remain stable as APIs evolve.