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/applications

• Short 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.

Action	Endpoint	Use when
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}/submit

Use 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 changesRequested

• the 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:

POST /merchant-onboarding/applications/{applicationId}/submit

For attachments, use the Application Attachments page before submitting the Draft application.

Endpoint

PUT /merchant-onboarding/applications/{applicationId}

Path parameter

Parameter	Description
applicationId	The onboarding application identifier returned when the application was created.

Authentication and headers

Onboarding requests use API key authentication.

X-Api-Key: {apiKey}
Content-Type: application/json
Accept: application/json

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:

1. Retrieve the current application status.

2. Confirm that the existing application should continue.

3. Confirm that the package should go back to the same signer.

4. Call PUT /merchant-onboarding/applications/{applicationId}.

5. Allow the merchant signer to re-open the hosted flow and submit corrections.

6. Track the updated application using GET /merchant-onboarding/applications/{applicationId}.

Example request

PUT /merchant-onboarding/applications/{applicationId}
X-Api-Key: {apiKey}
Content-Type: application/json
Accept: application/json

The current endpoint does not require a request body.

Example response

{
  "applicationId": "app-123exampleid",
  "envelopeId": "env-1111-2222-3333-4444",
  "status": "resubmitted"
}

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:

1. A user sees that an onboarding application still needs action.

2. Your system calls GET /merchant-onboarding/applications/{applicationId}.

3. Your portal shows the current status and indicates that action is required.

4. A user selects a resend action.

5. Your system calls PUT /merchant-onboarding/applications/{applicationId}.

6. The merchant signer receives the updated onboarding invitation and completes the hosted flow.

7. Your system continues tracking progress with GET /merchant-onboarding/applications/{applicationId}.

Status handling

Before resending, check the current application status.

GET /merchant-onboarding/applications/{applicationId}

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:

Status	Resend guidance
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:

1. Create the application with submitImmediately: false.

2. Upload attachments while the application is in Draft status.

3. Submit the Draft application for signature.

POST /merchant-onboarding/applications/{applicationId}/submit

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

Scenario	Expected result
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 applicationId when 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

• Submit Application

• Fee Configuration for Onboarding Applications

• Application Attachments

• Test the Full Onboarding Workflow in Sandbox

• Get Status

• Webhooks for Application Events

• Sample Payload

• Reference Guide