# Resend Application

## Resend Application

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

This applies to both:

* Full applications created with `POST /merchant-onboarding/applications`
* Minimal or “empty” applications created with `POST /merchant-onboarding/applications-short`

### 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
* keep the same application record instead of creating a new one
* preserve application identity while restarting the signer-facing flow

### Endpoint

```http
PUT /merchant-onboarding/applications/{applicationId}
```

#### Path parameter

* `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 merchant 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 pattern is:

1. Retrieve the current application status.
2. Decide whether the existing application should be re-sent instead of replaced.
3. Call `PUT /merchant-onboarding/applications/{applicationId}`.
4. Allow the merchant signer to re-open the hosted flow and submit corrections.
5. 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
```

If your environment requires a request body for this operation, follow the current OpenAPI spec and endpoint documentation for the supported request shape.

### 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}`.

### Best practices

* Reuse the existing `applicationId` when you want to preserve application history and status tracking.
* Use resend when the same merchant signer should correct or complete the existing package.
* 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 or creating a new one.

Using `PUT /merchant-onboarding/applications/{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.

### Related pages

* [Submit Application](https://developers.bead.xyz/onboarding/submit-application)
* [Get Status](https://developers.bead.xyz/onboarding/get-status)
* [Webhooks for Application Events](https://developers.bead.xyz/onboarding/webhooks-for-application-events)
* [Sample Payload](https://developers.bead.xyz/onboarding/sample-payload)
* [Reference Guide](https://developers.bead.xyz/reference-guide)