> ## Documentation Index > Fetch the complete documentation index at: https://docs.dimepayments.com/llms.txt > Use this file to discover all available pages before exploring further. # Get a Merchant's onboarding status > Where a merchant sits in onboarding, from first contact through to being boarded and able to take money. Use this to follow up an application you sent with `get-form-link` without having to ask us. `status` is the headline. `application_status` is the underlying application record, and is the field to read when `status` is `underwriting` — that column covers both "sent to the processor and waiting" and "more documents have been asked for", and only the second one needs you to do something. Rather than polling this, subscribe to the `application_status_changed` webhook, which carries exactly these fields and fires on every change. Poll only to reconcile after an outage. `status` is one of: `lead`, `discovery`, `proposal`, `application_in_progress`, `underwriting`, `live`, `cancellation_pending`, `churned`, `declined`. A merchant that has not started onboarding at all may report `null`. `application_in_progress` begins when the merchant opens the onboarding link and saves the first step — the application record does not exist until they do. So a link you requested and they never opened leaves them on `lead`, `discovery` or `proposal`: **no status currently tells you an invitation is outstanding.** If you need to chase unopened invitations, track when you called `get-form-link` on your side. `application_status` is one of: `draft`, `pending_review`, `submitted`, `approved`, `needs_documents`, `failed`, or `null` when no application has been started. A merchant can be `live` without `application_status` being `approved`. Declines and holds are resolved out of band with underwriting, and the signal that the account came good is the credentials that board the merchant. `boarded` is the ground truth for "can they take money". ## OpenAPI ````yaml https://app.dimepayments.com/openapi.yaml get /api/merchant/application-status openapi: 3.0.3 info: title: Dime Payments API Documentation description: >- A simple, basic API for managing Merchants through Dime Payments. JSON based REST API version: 1.0.0 servers: - url: https://app.dimepayments.com security: - default: [] tags: - name: Merchant management description: '' - name: Transaction management description: >- APIs for managing transactions. Depending on API KEY permissions, one should be able to charge credit cards, ACH, Google/Apple Pay wallets along with other functions. - name: Chargeback management description: '' - name: Document management description: '' - name: Addresses description: |- APIs for managing customer addresses - name: Customer management description: >- APIs for managing customers. Depending on API KEY permissions, one should be able to list, create, update, and delete customers along with several other customer specific requests. - name: Deposit management description: '' - name: Held funds description: '' - name: Invoice management description: >- APIs for managing invoices. Depending on API KEY permissions, one should be able to list, create, update, delete, and send invoices, manage their line items, and manage recurring-invoice schedules. Every request is scoped to a single Merchant via the required `data.sid`. - name: Payment Method management description: >- APIs for managing payment methods associated with customers. Depending on API KEY permissions, one should be able to list, show, create, update, and delete payment methods. - name: Recurring Payments management description: >- APIs for managing recurring payments. Depending on API KEY permissions, one should be able to create, edit, pause, cancel along with other functions. - name: Subscription Plans management description: >- Merchant-facing API for subscription plans (recurring offerings customers subscribe to). The merchant is identified by `data.sid`; the token must carry the matching `subscription-plan:*` ability. Mirrors the recurring-payment and invoice API controllers. - name: Subscriptions management description: >- Merchant-facing API for individual customer subscriptions (enrollments in a plan). The merchant is identified by `data.sid`; the token must carry the matching `subscription:*` ability. Lifecycle transitions delegate to the {@see \App\Actions\Subscription} action classes so the matching `SUBSCRIPTION_*` webhook always fires. Mirrors the recurring-payment and subscription-plan API controllers. - name: Zapier description: >- APIs for use through Zapier. Depending on API KEY permissions, one should be able to see customers and transactions data. paths: /api/merchant/application-status: get: tags: - Merchant management summary: Get a Merchant's onboarding status description: |- Where a merchant sits in onboarding, from first contact through to being boarded and able to take money. Use this to follow up an application you sent with `get-form-link` without having to ask us. `status` is the headline. `application_status` is the underlying application record, and is the field to read when `status` is `underwriting` — that column covers both "sent to the processor and waiting" and "more documents have been asked for", and only the second one needs you to do something. Rather than polling this, subscribe to the `application_status_changed` webhook, which carries exactly these fields and fires on every change. Poll only to reconcile after an outage. `status` is one of: `lead`, `discovery`, `proposal`, `application_in_progress`, `underwriting`, `live`, `cancellation_pending`, `churned`, `declined`. A merchant that has not started onboarding at all may report `null`. `application_in_progress` begins when the merchant opens the onboarding link and saves the first step — the application record does not exist until they do. So a link you requested and they never opened leaves them on `lead`, `discovery` or `proposal`: **no status currently tells you an invitation is outstanding.** If you need to chase unopened invitations, track when you called `get-form-link` on your side. `application_status` is one of: `draft`, `pending_review`, `submitted`, `approved`, `needs_documents`, `failed`, or `null` when no application has been started. A merchant can be `live` without `application_status` being `approved`. Declines and holds are resolved out of band with underwriting, and the signal that the account came good is the credentials that board the merchant. `boarded` is the ground truth for "can they take money". operationId: getAMerchantsOnboardingStatus parameters: [] requestBody: required: false content: application/json: schema: type: object properties: data: type: object description: '' example: [] properties: sid: type: string description: The unique SID of the Merchant. example: '00069' required: - sid responses: '200': description: '' content: application/json: schema: oneOf: - description: Success type: object example: data: sid: '00069' name: Acme Inc status: underwriting application_status: needs_documents boarded: false application_submitted_at: '2024-01-15T14:02:11+00:00' properties: data: type: object properties: sid: type: string example: '00069' description: The unique Dime Payments ID for the merchant. name: type: string example: Acme Inc description: The name of the merchant. status: type: string example: underwriting description: >- Where the merchant sits in onboarding. See the list above. application_status: type: string example: needs_documents description: >- The merchant application's own status, or null if no application has been started. See the list above. boarded: type: boolean example: false description: >- Whether the merchant holds processor credentials and can take money. application_submitted_at: type: string example: '2024-01-15T14:02:11+00:00' description: >- date When the application was sent to the processor, or null if it has not been. - description: Onboarding not yet started type: object example: data: sid: '00069' name: Acme Inc status: lead application_status: null boarded: false application_submitted_at: null properties: data: type: object properties: sid: type: string example: '00069' description: The unique Dime Payments ID for the merchant. name: type: string example: Acme Inc description: The name of the merchant. status: type: string example: lead description: >- Where the merchant sits in onboarding. See the list above. application_status: type: string example: null description: >- The merchant application's own status, or null if no application has been started. See the list above. boarded: type: boolean example: false description: >- Whether the merchant holds processor credentials and can take money. application_submitted_at: type: string example: null description: >- date When the application was sent to the processor, or null if it has not been. '400': description: Failed validation content: application/json: schema: type: object example: errors: data.sid: - The data.sid field is required. properties: errors: type: object properties: data.sid: type: array example: - The data.sid field is required. items: type: string '401': description: '' content: application/json: schema: oneOf: - description: Bad API Key Permission type: object example: data: message: Permission Denied. properties: data: type: object properties: message: type: string example: Permission Denied. - description: Not your merchant type: object example: data: message: Permission Denied properties: data: type: object properties: message: type: string example: Permission Denied '404': description: Unknown merchant content: application/json: schema: type: object example: data: message: No such Merchant properties: data: type: object properties: message: type: string example: No such Merchant components: securitySchemes: default: type: http scheme: bearer description: >- You can retrieve your token by visiting your dashboard and clicking Generate API token under your profile in top right. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.