Skip to main content

​
Version layers

Do not use one version as a substitute for another. A newer record can still follow the same schema; a recalculation under a new policy must retain its own provenance.

​
Breaking changes

Changing a field’s meaning, type, requiredness, units, sign convention, or calculation requires contract review and versioned client communication. Endpoint removal, changed authorization behavior, and changed idempotency or pagination semantics also require compatibility review. New optional fields can be additive when existing meanings remain intact. Enum additions must be announced. Retain raw provider statuses and handle normalized unknown values where the resource defines them.

​
Client guidance

Tolerate new optional response properties. Validate the fields your application relies on and fail safely when a critical contract assumption no longer holds. Do not fabricate a default score, currency, or approval state for an unknown value. Reject invalid request properties according to the documented request schema. Store schema and calculation versions with evidence used for decisions. Preserve immutable risk snapshots instead of rewriting the original assessment.

​
Release lifecycle

This reference documents API version 1.4.2. Your service agreement defines support windows and deprecation notice periods; follow the migration guidance provided for a version transition. Download and pin the OpenAPI contract used by your integration. Review a schema diff and rerun contract tests before adopting a new version.