Looking for how an applicant picks up an application your backend already filled in? That is a
different page: Pre-populating an
application. The onboarding
component finds the application on its own and needs no secret from you. Come back here when the
secret on such an application has expired, because this endpoint is what puts a live one back on
it.
DRAFT application and delivers it to the applicant by email.
POST /embedded-banking/v1/bank-account-applications/resume
Resume Request
Response (200 OK)
email against the applicant’s email on a DRAFT application owned by your credential’s organization. If a match exists, a fresh client secret is generated, hashed and stored, and the plaintext is emailed to that address. The plaintext is never returned in the HTTP response — the resume call is a server-to-server trigger; the secret reaches the applicant only via the email channel.
Always 200, by design
The response is always{ "acknowledged": true }, including when no matching application exists or the per-credential rate limit is exceeded. This prevents the endpoint from being used to enumerate applicant emails. A real applicant who does not receive the email should be retried after the rate-limit window or contacted out of band — the API will not tell you which case you are in.
DRAFT only
Resume only works while the application is inDRAFT. Once submitted, there is nothing left for the browser to do, so there is no secret to re-issue.
The resume endpoint is the only way to put a live client secret back on a
DRAFT application once
the previous one has expired. The create endpoint does not return an existing application’s secret
a second time, and GET never exposes it.