Swagger defines transport shapes and required parameters. The current API also applies controller checks and FluentValidation rules. A schema-valid example is not necessarily sufficient for an offer, approval or withdrawal.
Common rules
Use non-empty GUIDs for customer, application, partner, loan, applicant and supporting-document IDs. A selected bank-account id is a string from the account response. Keep dates in ISO 8601 format and use UTC for dateUTC values. Send dictionary values using the types declared in the selected schema.
Customer and application data
| Request | Requirements |
|---|---|
| UserRequest | First and last name required, each at most 50 characters. Email required, valid and at most 50 characters. Mobile required with exactly ten digits after punctuation is removed. Password at least eight characters, with uppercase, lowercase and a digit. |
| Bulk customers | Names required, each at most 30 characters. Email required, valid and at most 50 characters. Mobile and password required. Use the stronger individual customer rules for new integrations. |
| Create application | Existing non-empty customerId and a zip code supplied through businessZip or extraInformation.zipcode. Supply one zip representation, not both. |
| Combined customer/application | Customer data must pass UserRequest validation. Application zip code is also required. The older combined route is deprecated. |
| Combined customer/application/applicant | Customer validation plus application extraInformation.zipcode and extraInformation.ssn; businessZip may supply the zip code. Check the complete applicant schema. |
| Bulk applications | Non-empty businessName of at most 30 characters and non-empty extraInformation. |
| Update customer data | firstname, lastname, address, state, city, ssn, mobile and dateOfBirth are required query parameters. |
| Update application data | name, zipcode and startDate are required query parameters. |
The individual application validators do not establish all downstream business requirements. Supply meaningful business data and inspect the application result rather than assuming omitted fields are sufficient for approval.
Banking data
Supply at least one bank account. Each account requires accountName, accountNumber, accountType, bank, currentBalance, availableBalance and routing. Each supplied transaction requires amount and date. Balances and transaction amounts are strings in these models. Match the actual statement data and keep account identifiers out of logs.
Company, applicants and signatures
| Request | Requirements |
|---|---|
| CompanyDataRequest | businessName and entityType required, each at most 30 characters; businessTaxId, zipCode and city required. |
| PrimaryApplicantRequest | name required, at most 30 characters; email required, valid and at most 50 characters; mobile and driversLicense required. |
| SecondaryApplicantRequest | Primary applicant requirements plus non-empty miscellaneousData. An empty dictionary fails validation. |
| DrivingLicenseRequest | address, cardNumber, city, dateOfBirth, expiryDate, issuingState and name required. cardNumber at most 20 characters; city and name at most 30 characters. |
| SignaturesRequest | ipAddress, mimeType and both non-empty signatures required. Encode signature bytes as base64 strings. |
Company/applicant changes, bank selection, signatures and approval document uploads require an unexpired offer. The approval guide explains the sequence.
Calculations and invoice withdrawal
SliderRequest requires a non-zero amount. CalculationRequest requires a non-zero amount and terms between 7 and 52 inclusive. This terms rule applies to invoice calculations too. A positive amount appropriate to the available funds is necessary for a useful calculation.
Withdrawal start requests contain a calculation object with those fields. The handler compares the requested amount with available balance and the saved calculation. Invoice confirmation requires non-zero amount and advanceRate, dateUTC and otp. Use the agreed values and entered OTP rather than placeholder numbers.
The disabled LOC confirmation operation is not part of the current endpoint reference. Do not infer an available endpoint from an old request model or validator.
Messages, webhooks and files
Communication requires contents and user; user is limited to 30 characters. Loan and communication lists cap take at 200. Partner-application and invoice-customer routes do not apply the same cap; choose an explicit bounded page size.
For webhooks, send the required subscription body and exactly one target query ID. URI updates require webhookUri. Read back the subscription to confirm that it was saved.
Document uploads require non-empty decoded bytes no larger than 15 MiB. File names and required type/requirement IDs belong in query parameters; the file body is a JSON base64 string. See uploads and error handling.