Index
Changing the version of an API can change fields, authentication, and the meaning of responses. Contracting needs to identify all consumers before modifying the contract used in production.
How to evaluate this decision
Inventory external endpoints, operations, and dependencies. Compare mandatory changes and optional features of the new version. Define whether there will be temporary coexistence and how to measure adoption. Don't assume compatibility because a field name stayed the same: formats, possible values, and error rules are also part of the contract.
Criteria for comparing proposals
- Mapping: register consumers, responsible parties and affected operations.
- Compatibility: Test contracts with representative examples, including errors and missing fields.
- Transition: plan release, observation and retirement of the old version after confirming use.
A scenario to discuss with the supplier
Hypothetical example: a previously single status now has two distinct values. Translating both to the previous state may hide a necessary operational decision. Adaptation must address the meaning of the change.
What to validate upon delivery
Run the same suite of scenarios on both versions and compare the expected results. Monitor remaining calls to the old version before deactivating it.
Prepare the conversation about the project
Quantum9 can evaluate and adapt existing integrations. Provide documentation, end date, and known consumers to define a migration with explicit dependencies and rollback.
Integrations and APIs · Map the company's priority