Skip to main content
The primary controller on a bank account application is the only user who needs to pass the application’s KYC/KYB checks. Once the application reaches COMPLETE and the organization is live, you can add more users — accountants, ops staff, additional owners, anyone who needs to log in — without putting any of them through the application flow. These are authorized users.

​
When you need them

  • The signed-up business has more than one person who needs access. The controller did onboarding; a bookkeeper now needs read access to balances and transfers.
  • A platform admin at your company (Northfield Software) needs to log into a customer’s organization for support — invite an admin user rather than impersonating the controller.
  • You are migrating users from an existing system and want each one to land as their own identity rather than collapsing them all onto a shared login.
If you only ever need one human per customer organization — the controller alone — you can skip this page entirely. The application flow already provisioned that user.

​
How it differs from the controller

The controller is a beneficial-owner-grade record on the application; an authorized user is a permission-grade record on the organization. Don’t try to add additional beneficial owners through this endpoint — those belong on the application’s businessOwners array.

​
Creating an authorized user

POST /identity/v1/users creates the user inside an organization. The endpoint accepts both APP and USER tokens; your backend can mint users using its client-credentials token, or a user with the user:write:all scope can mint additional users from the organization itself.
Create an invited user
To create the user inside a child organization (a platform caller acting on behalf of a customer’s org), set X-Organization-ID to that child org’s ID. Without the header, the user lands in the caller’s own organization.

​
Invitation vs immediate activation

  • INVITED — Tesouro emails the user a one-time invitation link. They follow the link, complete sign-in on their OIDC provider, and the platform marks them ACTIVE. Use this when the user owns the email account and will set up their own access.
  • ACTIVE — The user is created already-active and skips the invitation step. Use this when your platform is doing single sign-on and the user will arrive with a valid JWT — there is no separate sign-up step to run.
A user that stays INVITED for too long can be re-sent the invitation; an ACTIVE user that needs to be paused can be disabled rather than deleted.

​
Calling Tesouro as an authorized user

Once a user is ACTIVE, your backend can mint a JWT for them and either exchange it for a REST access token or wrap it in a widget JWE — the same two flows you use for the controller. Tesouro does not distinguish controller from authorized user at the token layer; what differs is the role and permission set you assigned at create time.