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.Documentation Index
Fetch the complete documentation index at: https://docs.tesouro.com/llms.txt
Use this file to discover all available pages before exploring further.
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.
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.
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.| Step | State after | Auth options |
|---|---|---|
| Create application | DRAFT | Bearer |
| Read application | unchanged | Bearer; client secret (PII masked, browser only) |
| Edit applicant / business / owners | DRAFT | Bearer or client secret |
| Request a verification code | DRAFT | Bearer or client secret |
| Submit applicant or business verification | DRAFT | Bearer or client secret |
| Submit application | SUBMITTED | Bearer or client secret |
| Re-issue a client secret to resume | unchanged (DRAFT) | Bearer |
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 the business, 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.