This guide uses separate customer and application creation steps so that each returned ID has a clear purpose. Prerequisites: a completed API login, an assigned environment and an authorized partner account.
1. Create a customer
Send POST /api/Application/create-customer with the bearer header and this JSON structure. Replace every example value with approved test data and a unique password.
{
"firstName": "Example",
"lastName": "Developer",
"email": "developer@example.com",
"password": "REPLACE_WITH_UNIQUE_PASSWORD_1a",
"mobileNumber": "2025550100"
}On HTTP 200, save the response's id as customerId. Names are limited to 50 characters, email to 50 characters, and the mobile number must contain exactly ten digits after punctuation is removed. See validation for password rules.
2. Create the application
Send POST /api/Application/create-application?sendLink=false. Set customerId to the ID returned above; the GUID shown here is only a placeholder.
{
"customerId": "11111111-1111-4111-8111-111111111111",
"businessName": "Example Business",
"businessZip": "10001",
"extraInformation": {
"years": "7"
}
}Supply the zip code using either businessZip or extraInformation.zipcode. Do not send both: current create handlers add businessZip to the dictionary and can reject duplicate keys. Keep extraInformation values as strings. For years in business, send completed years as a numeric string from "0" to "99"; older integrations may use legacy bucket labels.
The response is a JSON string containing the new application GUID, not an object containing applicationId. Save it as applicationId. Add partnerId or agentId only when you have the appropriate assigned IDs; do not send all-zero GUID placeholders.
sendLink defaults to false. Setting it to true requests a customer application link. You can separately use POST /api/Application/send-application-link?applicationId=<applicationId> when a notification is intended.
3. Supply banking data
Use POST /api/Application/add-or-update-banking-data/{applicationId} with a BankingDataRequest body. Include at least one bank account, its required details, and the available transaction history. Account balances and transaction amounts are strings in this contract. If supplying bankName, send it as a query parameter.
For bank statement files, follow document uploads. An empty transaction array may match the JSON shape but does not establish that there is enough information for an offer.
4. Process once, then read status
Call GET /api/Application/process-application/{applicationId} when the application is ready for evaluation. This legacy GET performs processing and returns an offer GUID; do not use it as a polling call or automatically retry it after an uncertain result.
Read progress with GET /api/Application/application-status/{applicationId} and offer details with GET /api/Application/application-offer/{applicationId}. Keep the returned status string intact; do not invent a status enumeration or assume that an offer means approval is complete.
5. Complete approval and find the loan
Follow the approval guide for company details, applicants, bank account selection, signatures and required documents. The required steps depend on the application and offer.
When a loan is available, use GET /api/Loan/get-customer-loans/{customerId} and match its applicationId. Save its id as loanId; an application ID or offer ID is not interchangeable with a loan ID.
Choose other creation routes deliberately
The application reference includes combined creation and bulk routes. The older customer-and-application route is deprecated. Applicant creation variants have additional data requirements; they are not drop-in substitutes for the two calls above. For combined applicant creation, inspect the request schema and the required identity fields before sending a request.
After a timeout, look up existing customer/application records before attempting creation again. The current contract does not define an idempotency-key header.