# 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. ```http 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: ```http POST /merchant-onboarding/applications/{applicationId}/submit ``` For attachments, use the Application Attachments page before submitting the Draft application. ### Endpoint ```http 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. ```http 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 ```http 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 ```json { "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. ```http 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. ```http 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](/onboarding/submit-application.md) * [Fee Configuration for Onboarding Applications](/onboarding/fee-configuration-for-onboarding-applications.md) * [Application Attachments](/onboarding/application-attachments.md) * [Test the Full Onboarding Workflow in Sandbox](/onboarding/test-the-full-onboarding-workflow-in-sandbox.md) * [Get Status](/onboarding/get-status.md) * [Webhooks for Application Events](/onboarding/webhooks-for-application-events.md) * [Sample Payload](/onboarding/sample-payload.md) * [Reference Guide](/reference-guide.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developers.bead.xyz/onboarding/resend-application.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.