Credit Applications

The Thredd Credit Application API provides the endpoints and webhooks needed to build a credit application flow into your product, whether that's a mobile app, web interface, or an integration with an existing system. You can also retrieve existing applications for display or audit purposes. Note that creating an application is one step within a broader origination process that begins when a prospective borrower applies for credit.

This page provides an overview of:

• The credit application process
• The customer (applicant) information that you must collect and send to Thredd
• The endpoints and webhooks that you should use to create and receive updates about an application

Application Endpoints

The Application endpoints support the full credit origination flow, from retrieving available products through to submitting an application, responding to an offer, and tracking application status. Use these endpoints to build a credit application journey into your user interface.

For more information about the application process, see Credit Applications and Origination. The Application endpoints can also be viewed in the API Explorer.

Overview of the Credit Application Process

To enable customers to apply for a credit product, you must collect their information to create an application. This forms part of the wider origination process, which includes verifying an applicant's identity and suitability before deciding whether to make them an offer.

There are two use cases to consider when building a credit application flow:

• Standard review applications — these are subject to assessment by the credit decisioning engine. Thredd performs automated checks including identity verification, credit bureau checks, and fraud screening before issuing an offer.
• Pre-approved applications — where you (the lender) complete all required checks and pre-approve a customer prior to creating their application on the credit platform. These do not undergo credit decisioning within the Thredd platform. You must include the credit limit, cash limit, and interest rates in the request.

When you send a successful create application request to Thredd, it triggers the following automated processes:

• Creating a customer record on the credit platform
• Automatically linking the customer record to their credit application
• Checking applicant information and, for standard review applications, passing the application to the credit decisioning engine for processing
• Processing all mandatory checks
• Sending webhook messages with updates about the application status — for example, when an application is APPROVED or DECLINED

You should configure your application to receive webhook messages and notify the applicant when there are updates. For example, you could present decisions and offers to users in a mobile app or other user interface.

Credit Decisioning and Checks for Standard Review Applications

The credit decisioning process allows lenders to assess a prospective borrower's suitability for their products. Within the Thredd platform, the credit decisioning engine assesses applications that require decisioning using a combination of business rules specified by you and a series of automated checks. This assessment broadly includes:

• Identity and verification (ID&V) as part of a Know Your Customer (KYC) process and fraud checks
• Checking the applicant's credit history with a credit bureau, and risk assessment based on credit scoring, income, and other factors
• Affordability checks using preconfigured lending rules and the lender's policies

When you send a standard review application to Thredd, it has an initial status of PENDED. This means it must undergo checks and is pending a decision from the decisioning engine.

If the applicant needs to provide proof of their identity, they will receive an SMS with a link to a portal where they can upload the necessary documents.

Once credit decisioning is complete, the credit platform sends a webhook message with the result and the updated application status.

Pre-Approved Applications

The pre-approved application use case applies only when you have completed your own credit decisioning and due diligence checks outside the Thredd platform, and are ready to pre-approve a customer.

These checks are generally the same as those for standard review applications, such as a KYC process. The difference is that you complete this assessment prior to sending the application to Thredd. You must also include the credit limit, cash limit, and interest rates in the request payload.

Pre-approved applications submitted to Thredd do not undergo processing by the credit decisioning engine. Instead, Thredd validates the application data, creates and links the customer record, credit account, and product, and retains a record of the application. A line of credit and payment card are created immediately on successful submission.

Key Steps for Building the Application Flow

Your mobile app or user interface should include the features users will need after submitting an application, for example, a way to view application status, view and accept an offer, and receive updates.

Here is an overview of the key steps in the standard review application flow:

1. Collect information from the prospective borrower to create their credit application.
2. Create a credit application using the Create Credit Application endpoint.
3. Subscribe to webhook events about the application and communicate updates to the applicant.
4. Present the credit offer to approved applicants.
5. Send an update to Thredd when the applicant accepts or declines the offer.

Prerequisites

Before continuing, ensure that:

• Thredd has confirmed your configuration is complete and provided the unique productId for your credit product.
• You include the correct productId in all requests to the Create Credit Application endpoint. You can retrieve available products at any time using the Get Application Metadata endpoint.

1. Collect Information from the Prospective Borrower

Capture the necessary information from the person applying for your credit product in order to create an application — for example, their name, date of birth, address, contact details, and income information. Whether you capture this across one screen or multiple is up to you.

The fields below represent the information you must include in the request payload. For the full field reference, see Start Credit Application.

{
  "productId": "prod_123456",
  "title": "Ms",
  "firstName": "Known",
  "middleName": "Lee",
  "lastName": "Person",
  "nameSuffix": "JR",
  "dateOfBirth": {
    "year": 1990,
    "month": 4,
    "day": 15
  },
  "nationalId": {
    "idNumber": "123-45-6789",
    "idType": "SSN"
  },
  "customerType": "INDIVIDUAL",
  "gender": "FEMALE",
  "email": "[email protected]",
  "residentialAddress": {
    "addressLine1": "1234 Test St",
    "city": "Any Town",
    "state": "TX",
    "zipCode": "73301",
    "country": "US"
  },
  "phoneNumbers": {
    "mobile": "+14155552671",
    "primaryContact": "MOBILE"
  },
  "employmentStatus": "EMPLOYED",
  "occupation": "Administrator",
  "totalAnnualIncome": 72000,
  "monthlyRentOrMortgage": 1200,
  "bankAccounts": "CHECKING_AND_SAVINGS",
  "usCitizen": true,
  "dualCitizenship": false,
  "consent": true,
  "ipAddress": "10.0.0.0",
  "employerName": "Acme Corp"
}

2. Create a Credit Application

To create an application on the credit platform, send a POST request to the Create Credit Application endpoint.

POST {{baseUrl}}/api/v1/credit/applications

A successful request returns a 200 HTTP code. The response is the application object itself — there is no wrapper object. Note the following fields in the response:

• applicationId — the unique ID of the application, which you can pass to the Get Credit Application by ID endpoint to retrieve the stored application record and current status.
• status — the current status of the application; initially PENDED for standard review applications.

If the request contains invalid data or is incomplete, the system returns a 422 HTTP error and details of the validation failure.

{
  "applicationType": "standard_review",
  "applicationId": "app_123456",
  "status": "PENDED",
  "productId": "prod_123456",
  "title": "Ms",
  "firstName": "Known",
  "middleName": "Lee",
  "lastName": "Person",
  "nameSuffix": "JR",
  "dateOfBirth": {
    "year": 1990,
    "month": 4,
    "day": 15
  },
  "nationalId": {
    "idNumber": "123-45-6789",
    "idType": "SSN"
  },
  "customerType": "INDIVIDUAL",
  "gender": "FEMALE",
  "email": "[email protected]",
  "residentialAddress": {
    "addressLine1": "1234 Test St",
    "city": "Any Town",
    "state": "TX",
    "zipCode": "73301",
    "country": "US"
  },
  "phoneNumbers": {
    "mobile": "+14155552671",
    "primaryContact": "MOBILE"
  },
  "employmentStatus": "EMPLOYED",
  "occupation": "Administrator",
  "totalAnnualIncome": 72000,
  "monthlyRentOrMortgage": 1200,
  "bankAccounts": "CHECKING_AND_SAVINGS",
  "usCitizen": true,
  "dualCitizenship": false,
  "consent": true,
  "ipAddress": "10.0.0.0",
  "createdAt": 1736238041798277,
  "updatedAt": 1736238041798277,
  "clientAssignedId": 12345,
  "clientAssignedLocId": 67890,
  "employerName": "Acme Corp"
}

Application Status

When an application is first created, the status is generally PENDED. The status changes throughout the lifecycle of the application.

3. Subscribe to Webhook Events and Communicate Updates to Applicants

When the status of an application changes, Thredd sends a message via webhook. You must subscribe to Thredd webhooks so that you can receive these updates and communicate them to the applicant — for example, by displaying notifications or status updates in your mobile app or user interface.

Examples of events you should handle:

• When the status changes from PENDED, indicating that initial checks are complete
• When the applicant needs to provide additional information — for example, uploading identity documents to verify their identity
• When an offer is ready to present to the applicant

Depending on the outcome of the credit decisioning process, the application status updates to one of the following:

• OFFER_PENDING_ACCEPTANCE — the application has passed initial checks and an offer has been generated. Present the offer to the applicant so they can decide whether to accept or decline it.
• DECLINED — the application has been declined. Notify the applicant and reflect the status in your user interface. Thredd retains a record of the application but does not create a credit account.

4. Present the Credit Offer to Approved Applicants

When you receive a webhook notification that the application status has changed to OFFER_PENDING_ACCEPTANCE, you can retrieve the application's offerId — for example, via the Get Credit Application Timeline endpoint — to use when the applicant responds to the offer.

The applicant has 30 days to accept or decline the offer. If no response is received within that period, the application status is set to WITHDRAWN.

5. Send an Update to Thredd when the Applicant Responds to the Offer

When the applicant accepts or declines the credit offer, send an update to Thredd using the Respond to Line of Credit Offer endpoint.

POST {{baseUrl}}/api/v1/credit/applications/offers/{offer_id}/response

The offer_id may be included in the webhook notification received in Step 3; you can also retrieve it as the offerId field from the Get Credit Application Timeline endpoint. Pass it as a path parameter along with the applicant's decision in the request body.

{
  "accepted": true
}

Set accepted to true if the applicant accepts the offer, or false if they decline.

A successful request returns a 200 HTTP code. Depending on the value of accepted, the following occurs:

• Accepted (true) — the application status updates to OFFER_ACCEPTED. Thredd then performs a hard credit check. If approved, the application status updates to APPROVED, a line of credit account is created, and a payment card is issued. You will receive a webhook notification confirming the account is active.
• Declined (false) — the application status updates to OFFER_DECLINED. Thredd closes the application and retains a record for audit purposes. No credit account is created.