Versioning and changes
/v1 in the path, dated versions within it, and what ZyloPay may change without a new version.
The API has two levels of versioning.
- Major version in the path:
/v1. It changes only for a rewrite of the API. - Dated versions within v1, sent in the
ZyloPay-Versionheader. The current and only version is2026-09-28.
How your version is chosen
- Each API key is pinned to the latest version when it is created.
- Send
ZyloPay-Version: <date>to choose a version for one request. An unknown version answers400 api_version_invalid. - Every response echoes the version it was rendered with in the
ZyloPay-Versionheader. - Each webhook endpoint is pinned to a version too (
api_version, set at creation). Events delivered to it use that version's shape.
curl https://zylopay-api.fly.dev/api/v1/payments \
-H "Authorization: Bearer $ZYLOPAY_SECRET_KEY" \
-H "ZyloPay-Version: 2026-09-28"The Node SDK sends the version its types describe (ZyloPay.API_VERSION) with every request, so responses always match its types. Upgrading the SDK is how you move to a new version; new ZyloPay(key, { apiVersion }) pins another one.
What is not a breaking change
ZyloPay adds to v1 without a new dated version. Build your integration to tolerate:
- new endpoints;
- new optional request parameters;
- new fields in response objects and event payloads;
- new event types (you receive them only if your endpoint subscribes with
*or a matching family such aspayment_intent.*); - new error codes, decline codes and
reason_codevalues; - new values in enums such as
statusorcancellation_reason, where the documentation says the list may grow; - changes to
messagetexts and to the format of IDs after their prefix.
In practice: ignore fields you do not know, handle unknown codes by their type, and never parse messages or IDs.
What is a breaking change
Removing or renaming a field, changing its type or meaning, changing an endpoint's behaviour for the same request, or removing an event type. These ship only in a new dated version. Your keys and endpoints stay on their version until you move them.
Upgrading
When a new dated version ships, its changes are listed in the changelog.
- Read the changes for every version between yours and the new one.
- Test with
ZyloPay-Version: <new date>on a test key. - Create a new webhook endpoint on the new version and move your handlers, or update your code to accept both shapes.
- Create or rotate your live keys to pin them to the new version.
Changelog policy
- Every change to the public API is recorded in the changelog, additive or not.
- Breaking changes are announced before release, with the version date that carries them.
- Deprecated fields and endpoints keep working on the versions that have them.