Resend Application

Use this endpoint when you need to send an existing onboarding application back to the same signer so they can correct or update information and re-submit the package.

This operation:

• Re-initiates the signing envelope using the data currently stored on the application

• Sends a new onboarding email to the same signer on file

• Keeps the signer identity fixed; the signer cannot be changed by this operation

If you need a different signer, you must create a new application with the submit endpoint.

Resend applies to both:

• Full applications created with POST /merchant-onboarding/application

• Minimal or “empty” applications created with POST /merchant-onboarding/application-short

When to use Resend Application

Typical scenarios:

• Risk or operations reviewed the application and determined the merchant must correct or supply additional information

• The signer partially completed the package but needs to update previously entered details

• The original envelope expired or became stale and you want to re-open the flow with the same signer and data “from the front door”

• Support or sales teams need a one-click way to send the application back to the signer without changing the signer

Resend is not intended for:

• Changing the signer email or name

• Reboarding the same merchant under different commercial terms

• Creating a brand new application

Those use cases require a new application created via the submit endpoints.

Endpoint

PUT /merchant-onboarding/application/{applicationId}

Path parameter:

• applicationId The onboarding application identifier returned when you originally submitted the application.

Authentication:

• Requires a valid OAuth access token for the bead-integrator client.

• Use the standard Authorization header.

Example:

PUT /merchant-onboarding/application/app-abc123
Authorization: Bearer {access_token}
Accept: application/json

See the live API specification for the exact request and response contract for this endpoint.

Behavior

At a high level, calling this endpoint:

• Locates the existing onboarding application by applicationId

• Uses the signer already associated with that application

• Uses the current application data as the basis for a new signing envelope

• Sends a new onboarding email to the signer so they can open, review, change information, and re-sign

Key points:

• The signer identity is fixed The signer email and name remain the same. If a different person needs to sign, you must create a new application with the submit onboarding endpoint.

• The signer can change information The signer can update fields in the hosted onboarding experience according to your program and template configuration. The updated data becomes the new application state once they complete and submit.

• The application context is reused You are not creating a new application; you are sending the existing application back out for another complete signing pass. Your internal systems should continue to reference the same applicationId.

Exact rules about which statuses can be resent (for example, sent, delivered, completed, voided, expired) are defined by your program configuration and may be enforced by this endpoint. Always refer to the specification and your environment behavior.

Working together with Get Status

You should use the status endpoint to decide when resending is allowed in your UI or internal tools:

GET /merchant-onboarding/application/{applicationId}
Authorization: Bearer {access_token}
Accept: application/json

The response includes:

• status Current application status (for example, unsent, sent, delivered, completed, declined, voided, timedout and other related states)

• events Timeline of envelope events, which helps you understand whether an earlier envelope was sent, delivered, viewed, or completed

Recommended pattern:

• Allow “Resend application” when status is in a resend-eligible state for your program (for example, previously sent but not final)

• Do not show “Resend” when status is terminal for your use case (for example, completed, declined, voided, timed out), unless your program explicitly supports resending from that state

Encapsulate your allowed status list in your own code so the rest of your system just checks a single flag such as canResend.

Example flow in a portal

In a partner portal that shows merchant onboarding:

1. Store the applicationId when you first submit the application.

2. On the merchant detail page:

   • Call GET /merchant-onboarding/application/{applicationId}.

   • Show the current status and key timestamps.

   • If canResend is true for that status, show a “Send application back to signer” button.

3. When a user clicks “Send application back to signer”:

   • Your backend calls:

     PUT /merchant-onboarding/application/{applicationId}
     Authorization: Bearer {access_token}
     Accept: application/json

   • On success, display a confirmation such as “Application has been re-sent to the signer.”

   • Optionally log who triggered the resend and when.

4. Optionally, subscribe to onboarding webhooks so your system sees the new events (for example, new sent and delivered events after the resend).

Error handling

The specification defines the exact set of status codes and error models. In general you should expect patterns like:

• 200 or 204 when the application was successfully sent back to the signer

• 400 for invalid requests (for example, malformed application id)

• 401 when the access token is missing or invalid

• 403 when the caller does not have permission to act on that application

• 404 when no application exists for the given applicationId

• 409 or another non-success code when the application is in a state that cannot be resent in your program (for example, already completed and locked)

Always log error responses with the applicationId, HTTP status, and error body so operations and support teams can troubleshoot issues such as incorrect IDs, permissions, or attempts to resend closed applications.

Best practices

• Treat this as “send back to signer from the front door” This operation restarts the signing flow for the same signer with the current application data. It is ideal when compliance or risk has requested changes and you need the signer to go through the full experience again.

• Do not treat it as a signer change tool If the signer changes (for example, the business appoints a new authorized signer), submit a new onboarding application rather than resending.

• Combine with Manual Risk Feedback and Webhooks Use Manual Risk Feedback and event webhooks to know when an application needs more information, and then offer “Send application back to signer” to make that loop easy.

• Add light guardrails Consider rate limiting resends per application and restricting who can trigger them, so you do not spam signers with repeated emails.

Using PUT /merchant-onboarding/application/{applicationId} in this way gives you a clear “send back to signer” control that matches the current API behavior, while keeping signer identity and application identity stable.