Changelog and deprecations
This is where we announce changes to the Commerce API and upcoming retirements of fields and operations (deprecations). Check here before updating your integration.
The changelog will be populated with entries as the API is rolled out. At launch it may be empty — that means no announced changes or deprecations yet.
Versioning policy
The API contract is versioned, and we divide changes into two categories:
- Additive (compatible) changes — new optional fields, new operations, or new enum values that do not break existing integrations. We introduce them in the current API version. Your code should ignore unknown fields to stay resilient.
- Breaking changes — removing or changing the meaning of a field, changing
a type, or tightening requiredness. We do not introduce such changes in an
existing version — they go into a new version (e.g.
/v2), and the previous one remains supported for an announced period.
Compatible vs breaking
| Change type | Example | Where it lands |
|---|---|---|
| Additive (compatible) | New optional field in a response | Current version |
| Additive (compatible) | New operation or new webhook | Current version |
| Breaking | Field removed or type changed | New version (/v2) |
| Breaking | Optional field becomes required | New version (/v2) |
Deprecations
We mark fields and operations for retirement in advance. For each deprecation we will state: what it affects, the end-of-support date, and the recommended migration path. A field marked deprecated works until the announced deadline — plan your migration before that date arrives.
How to follow changes
We announce updates on this page. Changes to the contract itself are tied to its version and checksum — see Download API contract. If you have questions about how a specific change affects your integration, contact us through Support.