Versions and compatibility
Fictix has two distinct versions that integration teams should track.
| Version | What it identifies | Where to read it |
|---|---|---|
| API deployment release | The deployed backend build | /ready deployment metadata and release notes |
| Partner contract version | The normalized external response contract | contract_version in partner responses and /openapi.json |
Current partner contract
The current partner contract version is:
2026-07-17
It is a date-based string. Do not coerce it to a number.
Compatibility rules
- New optional fields and new catalog items can be added without changing the contract version.
- Clients must ignore response fields they do not recognize.
- A renamed, removed, or behaviorally incompatible public field/route requires a contract-version change and a changelog entry with migration guidance.
- Pin your integration tests to a staging company and record the deployed release, partner contract version, selected services, and catalog response.
The OpenAPI document specifies supported request bodies, auth schemes, and stable top-level response envelopes. Generated company records remain flexible by design; inspect the catalog for the selected service/object schema.
Upgrade checklist
Before moving an integration to a new Fictix release:
- Read the Changelog.
- Fetch the staging
/openapi.jsonand compare the partner paths you use. - Re-run your create/load/export or runtime test against a staging company.
- Verify error handling still accepts both string and structured
detail. - Store the release and
contract_versionwith your test result.
Deprecation discipline
Fictix will document a replacement route/field and a client action before a public contract removal. Internal project/admin routes are not part of this compatibility commitment unless they are explicitly added to these developer docs.
For Console-created companies, use the Console onboarding flow to rotate keys and test a staging integration before changing production.
