Versioning
How the API evolves.
Every endpoint is served under a version prefix — today that is /v1, e.g.
https://api.lite.shiftxpay.com/v1/payments. The version is part of the path, so
your integration pins itself to a contract simply by calling it.
Additive changes stay on /v1
We add to v1 without bumping the version. Treat the following as expected and
build a tolerant client that does not break when they happen:
- New endpoints and new optional request fields.
- New fields on existing responses — ignore properties you do not recognise.
- New event types in the webhook event catalog — only act on event types you subscribed to.
- New enum values — handle unknown values gracefully rather than asserting a closed set.
None of these require any change on your side.
Breaking changes get a new version
A change that could break a conforming client — removing or renaming a field,
changing a type, tightening validation, or altering the meaning of an existing
value — will not land on v1. It ships under a new path (/v2, …) and v1
continues to run during a documented migration window. The
changelog records anything notable.
Environments and keys
v1 mints sandbox keys today: API keys are issued in test mode with the
sk_test_ prefix, so you can integrate end-to-end against test PSP credentials
before any live traffic. Keep test and live keys in separate configuration and
never commit either to source control.