Resend Application
Use this endpoint to send an existing onboarding application back to the same merchant signer so they can complete, correct, or re-submit the package.
This endpoint applies to both:
Full applications created with
POST /merchant-onboarding/applicationsShort applications created with
POST /merchant-onboarding/applications-short
Resend keeps the same onboarding application record and sends the package back to the signer associated with that application.
Resend vs. submit Draft application
Do not use Resend Application to submit a Draft application for the first time.
Submit a Draft application
POST /merchant-onboarding/applications/{applicationId}/submit
The application was created with submitImmediately: false, attachments may have been added, and you are ready to send it to the signer for the first time.
Resend an existing application
PUT /merchant-onboarding/applications/{applicationId}
The application has already entered the signer-facing flow and needs to be sent back to the same signer.
If you created the application with submitImmediately: false, follow the Application Attachments workflow first, then call the Draft submit endpoint.
POST /merchant-onboarding/applications/{applicationId}/submitUse this Resend Application page only when you need to resend or reopen an existing application package for the same signer.
When to use Resend Application
Use Resend Application when you want to:
re-send an existing onboarding package to the same merchant signer
allow the merchant signer to correct missing or invalid information
let the signer complete steps they did not finish
re-open the hosted onboarding flow for a previously sent application
keep the same application record instead of creating a new one
preserve application history while restarting the signer-facing flow
Typical examples include:
the signer did not complete the package
the signer needs to correct information
the application moved to
changesRequestedthe same signer needs another opportunity to submit the package
your support or operations team wants to continue the original application instead of starting over
When not to use Resend Application
Do not use this endpoint when:
the application is still in Draft status and has not been sent to the signer yet
you need to upload attachments before the signer receives the application
you need to change the signer
you want to create a new application record
the existing application was withdrawn, rejected, or should no longer continue
For Draft applications, use:
For attachments, use the Application Attachments page before submitting the Draft application.
Endpoint
Path parameter
applicationId
The onboarding application identifier returned when the application was created.
Authentication and headers
Onboarding requests use API key authentication.
What this endpoint does
Resend Application sends the existing onboarding package back to the signer associated with the application.
Use this endpoint when the signer needs to:
re-open the hosted onboarding flow
correct information
complete missing steps
re-submit the application after prior review or follow-up
This flow is intended to keep the original application record in place rather than starting over with a new application.
Typical request pattern
A common resend pattern is:
Retrieve the current application status.
Confirm that the existing application should continue.
Confirm that the package should go back to the same signer.
Call
PUT /merchant-onboarding/applications/{applicationId}.Allow the merchant signer to re-open the hosted flow and submit corrections.
Track the updated application using
GET /merchant-onboarding/applications/{applicationId}.
Example request
The current endpoint does not require a request body.
Example response
Store the returned values and continue tracking the application by applicationId.
Example flow in a portal
A typical portal-driven resend flow looks like this:
A user sees that an onboarding application still needs action.
Your system calls
GET /merchant-onboarding/applications/{applicationId}.Your portal shows the current status and indicates that action is required.
A user selects a resend action.
Your system calls
PUT /merchant-onboarding/applications/{applicationId}.The merchant signer receives the updated onboarding invitation and completes the hosted flow.
Your system continues tracking progress with
GET /merchant-onboarding/applications/{applicationId}.
Status handling
Before resending, check the current application status.
Resend is most useful when the application is still intended to continue and the same signer should take action.
Common statuses that may lead to a resend include:
signing
Resend may be useful if the signer did not complete the package or needs a new invitation.
changesRequested
Resend may be useful after the signer needs to correct or complete information.
resubmitted
Continue tracking after a resend or correction flow.
signed
Usually do not resend unless your Bead team or operations process indicates the signer must take action again.
reviewing
Usually wait for review to complete unless directed otherwise.
boarding
Usually do not resend; the application has moved into downstream boarding.
boarded
Do not resend; onboarding is complete.
withdrawn
Do not resend unless your Bead team confirms the application should be reopened.
rejected
Do not resend unless your Bead team confirms the application should be reopened or corrected.
If you are not sure whether an application should be resent, retrieve the latest status first and coordinate with your Bead team if the status is terminal or unclear.
Resend and attachments
Attachments can only be added while an application is in Draft status.
If the application has already left Draft status, do not use Resend Application to add or replace attachments. Resend sends the existing package back to the signer; it does not reopen the Draft attachment window.
To include attachments before the signer receives the application:
Create the application with
submitImmediately: false.Upload attachments while the application is in Draft status.
Submit the Draft application for signature.
Resend and signer identity
Resend is intended for the same signer associated with the existing application.
Do not use Resend Application when you need to change the signer. If the signer needs to change, coordinate with your Bead team or create a new application if that is the correct operational path.
Error handling
Unknown applicationId
The request returns not found.
Application is not eligible for resend
The request may fail with a validation or conflict response.
API key is missing or invalid
The request returns unauthorized or forbidden.
Application is already boarded
Do not resend; use the boarded merchant record for downstream workflows.
Application was created as Draft and not submitted yet
Use POST /merchant-onboarding/applications/{applicationId}/submit instead.
Best practices
Retrieve the current application status before resending.
Use resend only when the same application should continue.
Use resend only when the same signer should receive the package again.
Do not use resend for Draft submission.
Do not use resend to add attachments after the application leaves Draft status.
Reuse the existing
applicationIdwhen you want to preserve application history and status tracking.Prefer resend over creating a new application when the original application is still the correct record to continue.
Keep your portal messaging clear so users know whether they are resending an existing application, submitting a Draft application, or creating a new one.
Continue tracking the application with Get Status after the resend.
Related pages
Last updated