Versioning helps partners keep integrations stable as Onyx capabilities change.
Partners should track SDK versions, catalogue versions, event changes, and migration notices in the same operational process they use for production releases.
SDK Versions
Connect SDK versions can affect:
- available methods
- validation behavior
- error handling
- consent helpers
- messaging helpers
- webhook support
Partners should test SDK updates before production rollout.
Catalogue Versions
Partner Connectivity catalogue versions can affect:
- package availability
- coverage labels
- data allowance
- validity period
- package status
- policy notes
- price fields where approved
Partners should store the catalogue version used at purchase.
Breaking Changes
A breaking change can require partner action.
Examples include:
- removed scope
- changed consent requirement
- retired package
- changed event shape
- required webhook signing update
- migration to a newer SDK version
Onyx should provide guidance when partner action is required.
Migration Notices
Migration notices should explain:
- what changed
- who is affected
- when action is required
- what the partner must update
- what happens if no action is taken
Partners should route migration notices to engineering, product, support, and operations owners.
Operational Updates
Operational updates can include:
- market availability changes
- package status changes
- webhook delivery changes
- reason code additions
- consent behavior changes
- support escalation changes
Partners should keep customer-facing copy aligned with the current approved behavior.
Partner Records
Partners should retain enough version history to diagnose issues.
Useful records include:
- SDK version
- catalogue version
- app config version
- consent copy version
- webhook endpoint version
- launch date
- migration completion date