Versioning
RAX Protocol uses explicit versioning to ensure stability, predictability, and long-term compatibility for developers.
Versioning applies to APIs, data schemas, and analytical models.
Why Versioning Matters
Risk intelligence systems evolve over time.
Models improve, data sources expand, and new analytical capabilities are introduced. Versioning ensures that these changes do not unexpectedly break existing integrations.
API Versioning
API versions are used to manage changes to endpoints and response structures.
Version identifiers are included in:
Endpoint paths, or
Request headers, depending on the integration
Breaking changes are introduced only through new API versions.
Schema Versioning
Data schemas may evolve independently of API endpoints.
Schema updates may include:
Additional fields
Extended metadata
Improved confidence indicators
Backward compatibility is maintained whenever possible.
Model Versioning
Risk scores and analytics are generated by internal models that may change over time.
Model versions are tracked to:
Ensure transparency
Support reproducibility
Allow historical comparisons
Model version information may be included in response metadata.
Deprecation Policy
When a version is scheduled for deprecation:
Deprecation notices are provided in advance
Documentation is updated accordingly
Migration guidance is made available
This process is designed to minimize disruption.
Best Practices for Integrators
Developers are encouraged to:
Pin integrations to specific API versions
Monitor changelogs and announcements
Test integrations against new versions before upgrading
These practices help maintain reliability.
Summary
Versioning provides a stable foundation for building on RAX Protocol.
It allows the system to evolve while preserving trust and integration continuity.
Last updated