Skip to main content
Every authenticated endpoint expects a bearer token:

Getting a token

Call Login with the email and password you registered with:
Use data.token as the bearer credential on onboarding, wallet, webhook, and partner-settings calls. Service endpoints — virtual accounts, transfers, bills payment, and subscriptions — accept this token or an API key. See below.
This login token expires. For a long-running service integration, prefer an API key on the service endpoints rather than re-logging in. Onboarding and settings still require this token.

Token lifetime — read this before you integrate

expires_in is seconds, and today that’s 7200 (2 hours) by default. There is no refresh-token endpoint. When a token expires, requests fail with 401 Unauthenticated and the only way to get a new one is to call Login again with your email and password. For a quick dashboard session this is normal. For a server-to-server integration that only calls service endpoints, use an API key instead — it does not expire on this 2-hour clock. If you are calling onboarding, wallet, webhooks, or partner settings unattended, your backend needs one of:
  • a small wrapper that catches 401s and transparently re-authenticates with a stored email/password before retrying, or
  • a scheduled re-login every ~90 minutes to keep a warm token on hand.
Neither is how most bank APIs expect you to integrate, and it does mean your service needs to hold your login password in a place your own backend can read it. We’re calling this out explicitly rather than letting you discover it the first time a long-running job 401s at 2am.

API keys

Issue an API Key returns an sk_live_... / sk_sandbox_... secret. Service endpoints accept either the login JWT or this key — virtual accounts, bills payment, and service subscriptions:
Onboarding, the wallet endpoints, webhooks, and partner settings still only accept the login JWT. A key sent to those routes is rejected. The key is scoped to the environment it was issued for.

Sandbox vs. live tokens

Your account has one environment setting (sandbox or live), switched with Switch Environment. A token is valid regardless of environment — it’s the account-level environment field that decides which ledger your service calls hit, not the token itself. See Sandbox vs. Live for the full picture.

Two-factor authentication

You can require a second factor on login via Toggle Two-Factor Authentication. This reference doesn’t yet cover the 2FA challenge flow in detail — if you’ve enabled it, reach out to support for the exact request shape.