Versioning and change policy

The API version

Every UniPay endpoint is version 1. Within v1:

• Additive changes can ship at any time — new endpoints, new optional request fields, new response fields, new error codes. Build your integration to ignore response fields it does not recognise.
• Breaking changes are avoided. When one is unavoidable, it is marked ⚠️ Breaking in What’s changed, with what you need to do, and it reaches the test environment before production.

A future v2 would run alongside v1, with its own docs.

Test first, then production

A change always reaches the test environment first. The build that is promoted to production is byte-for-byte the build that was tested — the API and these docs — so what you certified against in test is what you get in production.

Pages marked Preview describe something present in the build but not yet switched on for everyone. Don’t depend on it in production until the preview marker is gone.