Skip to main content
Business Accounts are in early access. See the overview for the model.
Most business account mutations require an elevated access token — a short-lived JWT scoped to a specific action. The regular session token is not enough. If the call proceeds without one, the backend returns a 403.

Which operations require step-up

These do not require step-up: createBusinessAccount, getBusinessAccount, listBusinessAccounts, createWalletForBusinessAccount.

Check whether step-up is needed

checkStepUpAuth does a fast local check first — if a valid elevated token for the scope is already in state, it returns { isRequired: false } without a network round-trip. Only if a fresh token is needed does it call the backend.

How to obtain an elevated token

Option 1 — MFA / passkey verify with requestedScopes

Pass requestedScopes when verifying with MFA, a passkey, or email OTP. The SDK parses the elevated token from the verify response and stores it automatically.
The same requestedScopes parameter is available on authenticateTotpMfaDevice, verifyOTP, and signInWithSocialPopUp.

Option 2 — External auth assertion (server-side)

If your backend issues its own JWTs (registered via your environment’s JWKS URL), mint a short-lived JWT containing sub, scope, jti, and exp claims and pass it to requestExternalAuthElevatedToken.

Option 3 — Step-up challenge flow

Use the credentials and defaultCredentialId from checkStepUpAuth to drive your own challenge UI, then pass the completed credential to a verify call with requestedScopes.

Putting it together

The SDK retrieves the stored elevated token and attaches it as x-dyn-elevated-access-token on the request. You do not pass the token manually.

Error handling

If the elevated token is missing or expired, the backend returns a 403. Catch it and prompt for re-verification:
Last modified on August 5, 2026