After a user authenticates, you need a way to represent their session on your own backend and check permissions on subsequent requests. 36Blocks supports two models for this. Pick whichever fits your architecture.

Use proxy_auth_token directly as the session token.

• It's required on every 36Blocks API call.

• You can store it in a cookie.

• It expires when the configured session time elapses, or when the user logs out.

• If any API call returns 401, treat the token as expired. Try the user's refresh token first (see ), and send the user to login only if that fails.

• The token itself carries no data. If you need current user, company, or permission info, call GET /c/getDetails whenever you need it, rather than relying on the token.

Call generateAuthToken with the user's proxy_auth_token and your admin AuthKey to get a JWT containing the user, their current company, and their role/permissions in that company.

36Blocks APIs still require the proxy_auth_token, so you'll need to keep a mapping from JWT to proxy_auth_token (e.g. in Redis, or your own approach) so you can look up the right proxy_auth_token when a request arrives with a JWT.

POST /c/switchCompany also returns a fresh JWT in its response, reflecting the new current company. Use that JWT directly. There's no need to call generateAuthToken again after switching companies.

The token-only model is simpler to set up (no extra infrastructure) but costs more API calls, since you'll be calling getDetails repeatedly for data the JWT could have carried. The JWT model front-loads user/company/permission data into the token itself, but requires you to maintain a token-to-JWT mapping.

Sessions end after your Block's Session Time. To avoid sending users back to login, store the refresh_token returned at login and exchange it for a new session. See .