Authentication

Every call to the mybanx API (other than POST /auth and POST /auth/refresh themselves) requires a
Bearer token in the Authorization header.

1. Get your first token

Call POST /v{version}/auth with the ApplicationKey and ClientKey you find in the "Applications" menu:

POST /v2/auth
{
  "applicationKey": "2bba77da-59eb-4b6c-bc12-1d7d0defd73a",
  "clientKey": "c1134f13-7685-4051-8113-98746e485672"
}

You get back:

{
  "bearer": "eyJhbGciOi...",
  "refreshToken": "5b1f...a90c",
  "validUntil": "2026-08-23T10:15:00Z",
  "executionId": "..."
}

bearer — send this as Authorization: Bearer <token> on every API call. Valid for 2 hours.
refreshToken — save this. Valid for 30 days. Use it to get a new bearer without resending your
ApplicationKey/ClientKey.

2. Renew your token

Once your bearer is close to validUntil, call POST /v{version}/auth/refresh:

POST /v2/auth/refresh
{
  "refreshToken": "5b1f...a90c"
}

You get back a fresh bearer, a new validUntil, and a new refreshToken. Store the new
refreshToken and discard the old one — each refreshToken can only be used once.

Why /auth/refresh can return 401

POST /auth/refresh returns 401 Unauthorized in any of these cases:

the refreshToken is unknown or malformed
it has expired (older than 30 days)
it has already been used — see "Reuse detection" below
it was revoked
your license/trial has ended since the token was issued — refresh re-checks this on every call, so a
token that was valid yesterday can start failing once the underlying license expires, even though the
token itself hasn't

In every case, call POST /auth again with your ApplicationKey/ClientKey to start a new session.

Reuse detection

Each refreshToken is single use: successfully refreshing invalidates it and issues a new one in its place.
If a refreshToken that was already used is presented again, we treat this as a sign it may have leaked —
every refresh token issued for that ClientKey is revoked immediately, not just the one you sent. The
next call to /auth/refresh, even with what looks like a still-valid token, will then fail until you
re-authenticate with POST /auth.

This is easy to trigger by accident if multiple processes or instances share the same ClientKey and
refreshToken: whichever one refreshes first rotates the token, and the next one to use the now-stale token
revokes the whole chain for everyone. Use a separate ClientKey per instance, or centralize refresh through a
single process, to avoid this.

Existing integrations

If your app already re-calls POST /auth with your ApplicationKey/ClientKey every time its token expires,
nothing changes for you — that flow still works exactly as before. Adopting refreshToken is optional and
lets you avoid resending your ApplicationKey/ClientKey on every renewal.