™2 min read
What v1 guarantees
The version is in the path so it is explicit and unmissable. Inside v1, changes are additive: new endpoints and new response fields may appear, but existing fields keep their name, type and meaning. That means a well-written integration keeps working as the platform grows — as long as you ignore fields you do not recognise rather than rejecting them.
Write tolerant parsers
Follow the robustness principle: be liberal in what you accept. Do not fail if a response contains a field you have never seen; do not assume the order of array elements beyond what the docs promise (the loyalty tiers, for instance, are documented as Bronze→Platinum order). This keeps your integration resilient to additive change.
How a breaking change would arrive
If the platform ever needed to change behaviour incompatibly, that would land under a new version prefix (a hypothetical /public/v2), with v1 kept running during a migration window. You would never wake up to a changed v1.
Frequently asked questions
Will new fields appearing in a response break me?
Only if your parser rejects unknown fields. Write tolerant parsers that ignore what they do not recognise, and additive changes within v1 will never break you.
How would a breaking change be delivered?
Under a new version prefix, not inside v1. The existing version would keep running during a migration window so you have time to move.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.