Skip to main content

​
How MarketOne Ensures Stability, Predictability, and Safe Evolution for Resellers and Merchants

MarketOne continuously evolves to improve reliability, security, performance, and functionality. This document explains how MarketOne manages changes in a safe, predictable manner so that Resellers and Merchants can integrate with confidence.

​
Core Commitments

We do not introduce breaking changes without controlled processes. MarketOne ensures that all breaking changes follow a structured release process, allowing Resellers and Merchants to understand the impact, prepare, and migrate safely. This includes clear identification of breaking vs. additive changes and controlled rollout windows. Additive-by-default evolution Most changes MarketOne introduces are additive and non-breaking, such as:
  • Adding optional fields
  • Adding new endpoints
  • Adding new columns in reports. These additions should not impact existing integrations.
Pre‑production releases for customer testing Every change, whether additive or breaking, is deployed first to the MarketOne pre‑production environment, typically one week before production, to allow Resellers and merchants time to:
  • Test business flows
  • Validate integrations
  • Raise concerns or feedback. This ensures issues can be identified before any production impact. (pre‑release staging principle)
Transparent lifecycle communication Changes undergo a clear lifecycle: Pre‑Production → Production Release → Deprecation (if applicable) → End‑of‑Life. Responsibility to update before deprecation deadlines Resellers and Merchants must update to supported versions before the deprecation date provided by MarketOne.
  • If MarketOne does not specify a deprecation date, we recommend upgrading as early as possible to benefit from the latest security, performance, and compliance improvements.

​
API Evolution Strategy

MarketOne APIs evolve while prioritizing stability for all Resellers and Merchants. This section covers all API surfaces, including REST APIs, webhooks, and notification events. Additive Changes (Safe) These are introduced without requiring customer action and include:
  • New optional request or response fields
  • New endpoints
  • New enum values
  • New metadata fields
Such changes are fully compatible with existing integrations. Additive Changes (Safe) If a change requires removing fields, altering formats, or changing behavior in incompatible ways, MarketOne will introduce a new API version and deprecate the previous version. The deprecated version will be marked with a deprecated indicator directly in the API specification so customers can identify it at a glance. MarketOne provides a one-year end-of-support window from the date of deprecation. During this period, the deprecated version remains available but receives no new development. Resellers and Merchants are expected to migrate to the new version before the end-of-support date. At the end of that period, MarketOne will remove the deprecated version. For every breaking change, MarketOne will:
  • Provide advance notice
  • Publish documentation and migration guidance
  • Deploy the change to pre-production one week before production release
  • Mark the deprecated version in the API specification with a deprecated indicator

​
Reporting & Data Schema Strategy

MarketOne reports are widely used by Resellers and Merchants for settlement, reconciliation, and financial decision-making. Stability is critical. Additive evolution (default) MarketOne evolves reports using safe, additive changes that do not alter existing columns, rows, or logic. Additive changes include:
  • New columns — additional attributes appended to a report without modifying existing columns
  • New records for new enumerated values — for example when a new value is introduced to an existing dimension, it appears as a new row in the report, not as a new column.
Additive changes do not include modifications to column definitions, column ordering, the logic used to calculate column values, or the removal of any existing field. Breaking schema changes (controlled) A report change is considered breaking — and follows a controlled process — in any of the following cases:
  • A column is removed or renamed
  • The logic used to generate the values in a column is refined or redefined
  • A data type or format changes in a way that is incompatible with existing consumers
If a report schema must change in a breaking way, MarketOne will:
  • A new report version will be introduced
  • Keep the existing version available for the deprecation window
  • Deploy the change to pre-production one week before production release
Report deprecation: If MarketOne needs to deprecate a report entirely, a minimum of one year’s advance notice will be provided before the report is removed. This will be communicated through MarketOne Trust Posts and reflected in the report’s description documentation, which will carry a deprecated marker for the duration of the notice period. Column logic refinements as breaking changes: Any change to the logic governing how a report column is generated is treated as a breaking change, regardless of whether the column name or type changes. Such changes will be communicated in advance through the standard breaking-change process defined in the communication channels section.

​
Admin UI and Experience

Advance Announcements of UI Changes MarketOne will announce UI updates in advance as “What’s Coming” notifications to Resellers and Merchants. These communications will include:
  • Overview of UI changes
  • Expected release dates
  • Screenshots or mockups
Documentation and Guides Delivered Before UI Rollout Ahead of UI changes reaching production, MarketOne will provide:
  • Updated user guides
  • Configuration instructions
  • Visual walkthroughs
This ensures operations teams can prepare before the change goes live.

​
Deprecation, Migration and End‑of‑Life

Deprecation Timelines MarketOne commits to providing a minimum of one year of continued availability after a deprecation is announced for an API version or report. Resellers and Merchants will receive the deprecation date at the time of announcement and are responsible for migrating before that date. Migration Support For any breaking changes or deprecations that require Resellers or Merchants to make changes or migrate away from a deprecated version, Resellers and Merchants should refer to the published documentation — including release notes and technical specifications — for migration guidance. If further details are needed, Resellers and Merchants can reach out to MarketOne Support for additional migration instructions, validation test cases, impact descriptions, and the list of affected components. Security or Third-Party-Forced Changes Some deprecations may be accelerated due to:
  • Security vulnerabilities
  • Infrastructure provider changes
  • Third-party API or certificate expirations
In such cases, MarketOne will communicate timelines as early as possible and provide guidance to minimize disruption.

​
Communication Channels for Change Announcements

Pre-Release “What’s Coming” Notifications One release before any change — additive or breaking — reaches production, MarketOne will publish a “What’s Coming” notice. This gives Resellers and Merchants advance visibility into changes expected in the upcoming release so they can plan, test, and raise concerns before the change ships. Transparent Announcements via Trust Posts and Release Notes All changes — additive or breaking — will be communicated through:
  • MarketOne Trust Posts — for high-visibility updates including breaking changes, deprecations, and end-of-support dates
  • Release Notes — for the complete record of every change in each production release