Skip to main content
A bank account application is a first-class object in the Embedded Banking API. Your backend creates it, applicant and business details get filled in, the bank decisions it. Each application moves through three states, and which credential you use to act on it depends on whether a browser is involved.

​
Integration shapes

How you drive an application depends on whether a browser sits between you and the API.
  • Server-to-server only. Your backend holds a bearer token and drives the entire lifecycle — create, edit, verify, submit — from server code. The client secret is never issued. Pick this when you’ve already collected applicant and business details out of band, or when KYC/KYB happens outside Tesouro and the application is essentially a system-of-record entry for the bank.
  • Server creates, browser finishes. Your backend creates the application and receives a short-lived application client secret in the create response. You hand the secret to a browser surface — your own UI, the white-label hosted app, or the onboarding widget — and the browser drives the rest without holding a backend bearer token. Pick this when end users need a UI.
The scoped client secret is a browser credential, not a server-side one. Backend integrators have no reason to issue one, and never need to think about the resume flow.

​
States

DRAFT

Editable. The applicant can update applicant, business, and beneficial-owner details and request the verification codes that precede submission.

SUBMITTED

Read-only. The applicant has called the submission endpoint; the bank’s KYC/KYB pipeline is running. Your backend can read the application but no one can edit it.

COMPLETE

Terminal. The bank has finished processing and the underlying bank account exists. The application is read-only and the client secret is invalidated.
Transitions only ever move forward: DRAFT → SUBMITTED → COMPLETE. There is no edit-after-submit and no return to DRAFT from a later state. If a submitted application is rejected by the bank, that outcome is reported through the bank account status — not by transitioning the application backward.

​
Auth at each step

Per-application calls accept either a backend bearer token (from the client credentials flow) or the application client secret — whichever credential the caller actually has. Backend-only integrations use bearer for every row. Hybrid integrations use bearer to create and resume, and the browser uses the client secret for the per-application rows in the middle. The client secret accepts only those per-application rows — it cannot create a new application, resume another one, or reach non-application endpoints. It is invalidated when the application reaches COMPLETE. After that, the application is reachable only with a backend bearer token. See Application client secret for token shape, header, and PII-masking rules.

​
Where to next

Creating an application

Create the application server-to-server, receive the client secret, and act on behalf of a child organization with X-Organization-ID.

Editing and submitting

Patch in remaining details, verify the applicant, and submit the application to the bank.

Resuming

Re-issue a client secret for a stale DRAFT application and deliver it to the applicant by email.