The Application Flow

The application is where a financing offer becomes a signed agreement. It is fully hosted by Slate and embedded in your platform — the customer never leaves your product, and your platform never collects or forwards any of the application data. You open it either through the pre-approval banner (which launches it on click) or by embedding slate-application-form directly.

The application is created the moment the customer opens it — that's when you receive the application.created webhook.

There are two variants of the flow:

• Standard — the customer applies for the pre-approved offer as-is, and Slate decides the final terms.
• Adjust terms — the customer configures their own loan (amount, term, payment frequency) within the limits of their offer.

Both are covered below.

The components are authenticated with a session token you mint server-side for the logged-in customer (POST /user-session-token) — see Capital, Step 4. Webhooks are delivered and signed, see Webhooks.

Embed options

Two attributes on the embed change how the flow behaves:

<slate-application-form
  env="live"
  user-token="<session-token>"
  skip-intro
  adjust-terms
></slate-application-form>

Both attributes also exist on slate-pre-approval-banner-v2 and slate-capital, and apply to the application they open.

What the customer is asked

The screens depend on the customer type:

Any information you already provided is not asked again. If you sent the customer's details when creating them (POST /customers) or via an update, the corresponding screens are simply not shown — the customer only fills in what's missing. The more complete the data you send upfront, the shorter their application.

The bank connection screen connects the customer's bank account through Flinks. This is the account Slate disburses the funds to and debits the repayments from.

The standard flow

Customer opens the application ──► DRAFT
        │   confirms details, connects their bank (Flinks)
        ▼
Submitted ──► PROCESSING ──► webhook: application.submitted
        │   Slate underwrites and decides
        │
        ├──► Rejected ──► webhook: application.rejected — the flow ends
        ▼
Approved with terms ──► REQUIRES_ACTION ──► webhook: application.ready-to-accept
        │   1. the customer verifies their identity (IDV)
        │   2. the customer reviews the approved terms and accepts
        ▼
APPROVED ──► webhooks: application.approved · preapproval.consumed
             financing-agreement.created

1. The customer completes the form

The customer confirms their details and address, then connects their bank. Once the bank is connected, the application is submitted automatically — status moves to PROCESSING and you receive application.submitted (and application.bank.verified for the bank account).

2. Slate underwrites and decides

Slate reviews the application and makes a decision:

• Rejected — you receive application.rejected and the flow ends there.
• Approved with terms — Slate approves the application with a specific set of financing terms.

3. Two pending actions before the agreement

After approval, the application status becomes REQUIRES_ACTION and you receive application.ready-to-accept. The customer has two things left to do, in order:

1. Identity verification (IDV) — a camera-based verification of the customer's ID document.
2. Review and accept the terms — the customer sees the approved agreement terms: amount, factor rate, payment amount and schedule. Before accepting, they can reduce the amount — but never request more than what was approved.

4. Acceptance

When the customer accepts, the terms are final and executed: you receive application.approved, preapproval.consumed, and financing-agreement.created. From here the flow continues with the financing agreement — see Capital, Step 7.

The adjust terms flow

With adjust-terms enabled, the customer doesn't apply for the offer as-is — they configure their own loan. An extra screen appears after the details and address:

• Amount — anything up to the offer's maximum.
• Term — how many months to repay over.
• Payment frequency — weekly or monthly.

As the customer adjusts these, Slate recalculates the resulting payment amount, fee and full payment schedule live, so they see exactly what they'd be committing to before continuing.

Customer opens the application ──► DRAFT
        │   confirms details, selects their terms, connects their bank
        │   verifies their identity (IDV)
        ▼
Submitted ──► PROCESSING ──► webhook: application.submitted
        │   Slate underwrites the requested terms
        │
        ├──► Terms accepted ──► agreement created, confirmation emails sent
        │                       webhooks: application.approved · preapproval.consumed
        │                                 financing-agreement.created
        │
        ├──► Counter-proposal ──► REQUIRES_ACTION: "Confirm adjusted terms"
        │           │   the customer reviews Slate's proposed terms and confirms
        │           ▼
        │    agreement created with the confirmed terms
        │
        └──► Rejected ──► webhook: application.rejected

How it differs from the standard flow:

• The customer selects the terms first. After choosing them and connecting their bank, they complete identity verification (IDV) as part of the same flow — before submission, not after approval.
• Underwriting evaluates the customer's requested terms. Three outcomes:
  • Accepted — the agreement is created directly with the terms the customer selected, and the confirmation emails are sent. No extra acceptance step.
  • Not accepted, but Slate has a counter-proposal — the customer gets a "Confirm adjusted terms" required action: they review Slate's proposed terms and must confirm them before the agreement is created.
  • Rejected — application.rejected, the flow ends.

Adjust terms mode applies to pre-approval offers only — it is not available for applications opened from a finance request (the Early Wage Access flow).

Application states

Check the current state any time with GET /v2/applications/{id}.

Webhooks

data.id in every application.* webhook is the application id. As always, webhooks carry only the id — fetch the current state from GET /v2/applications/{id}.