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

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.

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

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

• Get Status

• Webhooks for Application Events

• Sample Payload

• Reference Guide