API Change Management Policy

Appxite

Introduction

The API Change Management Policy describes how changes to APIs are controlled and managed within AppXite. This comprehensive guide outlines the systematic approach to collect, review, respond to, implement, communicate, and record change requests for all public APIs developed and managed by AppXite.

In this article:

Definition and Scope

Definition of Change: The creation of a new API(s) or any activity that changes the existing API structure, including, but not limited to, URL, headers, parameters, body, and payload.

In Scope: All public APIs are developed and managed by AppXite.

Not in Scope: 3rd party APIs. Examples: Microsoft Partner Center APIs.

API Maintenance and Versioning

Upon introducing changes to the APIs, such changes must be reflected according to the established version control framework. All API modifications follow a structured approach to ensure consistency and maintain partner integration stability.

Version Control Format

API version control uses the following standardized format:

  • Major version releases: x.0 (Example: 2.0)
  • Minor version releases: 0.x (Example: 0.3)

Versioning Principles

Major Version Releases

Major version releases shall apply to breaking changes, such as:

  • Modifications of existing fields or API parameters that change current behavior: Changes to existing fields or parameters that remove data or options, change payload structure, or otherwise change the way things work making it backward incompatible
  • Removal of fields or parameters: Some of the existing integrations will no longer operate in a new version

Minor Version Releases

Minor version releases shall apply to non-breaking changes, such as:

  • New fields or parameters that are optional are being added to the API, but the existing fields and parameters are unchanged

Version Immutability

NOTE! Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

Backward Compatibility Requirements

Upon releasing the new major API version, the previous version shall be maintained for the period of 6 months following the new version release. After this period, the previous version will be deactivated. As a result, for 6 months both the previous and current versions will work as expected for the Partners that are using them.

Documentation Requirements

  • Documentation availability: Documentations must be available for each version
  • API Header requirement: Major version should be required parameter in API header when calling public APIs
  • Example usage: Api-Version: v2

Summary

The API Change Management Policy ensures controlled, traceable, and partner-friendly API evolution through structured versioning, comprehensive documentation, and backward compatibility support. This systematic approach maintains integration integrity while enabling continuous API improvement and enhancement.

Related Content

Was this article helpful?

0 out of 0 found this helpful

Add comment

Please sign in to leave a comment.