Versioning

The Wajub API is versioned by date. Your account is pinned to the version that was current when you created it, and a breaking change ships under a new date without touching your integration. The current version is 2026-10-11.

Supported versions

New accounts are pinned to 2026-10-12; an existing account keeps its version and reaches a newer one with the X-Wajub-Version header. Webhooks follow the current version. The changelog says what each version changes.

A version stays supported for at least six months after it is superseded, and the removal is announced before it happens. An announced version is served to whoever asks for it with the header, so you can try it before it becomes current; no account is moved to it.

Choosing a version

Three sources are consulted, in this order: the X-Wajub-Version header on the request, the version pinned on your account, then the platform default.

Authorization: sk.xxxxxxxxxxxxxxxx...
X-Wajub-Version: 2026-08-01

The header only counts if it matches YYYY-MM-DD. Anything else, a v2, a latest, an empty string, is ignored in silence and your account's version applies instead. A well-formed date that is not on the supported list is a hard error:

From a browser, a page may send X-Wajub-Version with a public key: the preflight accepts it, and the 400 above carries the CORS headers, so the page reads the message instead of a CORS failure.

Every response says which version answered

X-Wajub-Version comes back on every response, including errors and the 400 above, and a page's code can read it. Log it: it is the fastest way to find out that a service you forgot about is still pinned to an old date.

curl -i https://api.wajub.com/transfers/po_225KMKULRQqYvlhrgUOE \
-H "Authorization: $WAJUB_API_KEY" \
-H "X-Wajub-Version: 2026-08-01"

Translation happens on both sides

Pinning a version keeps that version's whole contract, in requests and in responses.

What counts as breaking

A security change to what a key reaches or reads is the exception: it applies to every version at once, and the changelog says so where it happens.

Moving to a new version

1. 1

   Read what changed

   The changelog lists the diff for each date, field by field.

2. 2

   Test with the header

   Send X-Wajub-Version with the new date using a sandbox key. Nothing on your account changes, so you can run it alongside your current integration for as long as you need.

3. 3

   Roll it out per service

   Keep the header in place while you deploy, one service at a time. A service you have not migrated keeps answering on the old date.

4. 4

   Pin the account, drop the header

   Once everything runs on the new date, ask support to move your account's pinned version, then remove the header. Konsole → Overview shows which version your account is pinned to and which one is current, so you can confirm the change landed.