Activate AI inside your lending operation

Embed underwriting intelligence inside the lending workflow you already run.

Give lender ops, credit, and platform teams a developer path from API plan to first package in minutes. Submit loan packages, store credit policies with strict rule and checklist control, and retrieve review-ready dashboard.json plus PDF outputs without turning underwriting into a black-box decision.

Core integration signals

Built for lending teams

Underwriting intelligence, not generic OCR

The API is aimed at fintechs, lending platforms, and lender engineering teams that need structured underwriting output they can drop into an existing workflow.

Outputs that travel

dashboard.json plus PDF

Every completed job can return structured dashboard output for systems and an on-demand PDF report for credit and ops review.

Policy control

Stored policies with strict hashes

List policies, inspect hashes, replace policy specs, reextract from new source, and force a selected stored policy at processing time.

Trust boundary

Documents ephemeral, humans in control

Loan documents are processed ephemerally for API jobs, while credit decisions remain owned by your team and policy.

Activation path

Ship the first package before you add policy complexity.

API buyers care about the shortest path to real value. The first-run lane proves you can create the account, create the key, submit a package, and retrieve review-ready outputs before you invest in stored policy governance.

  • Create an account and start the API plan.
  • Generate an API key.
  • Submit a first loan package to /api/v1/process.
  • Store statusUrl, accessToken, and customerKey together.
  • Poll the job, retrieve dashboard.json, and download the PDF report.
  • Add stored credit policies only when you want policy-aware evaluation or a selectedPolicyId override.
POST /api/v1/process
1curl https://api.loanintelligence.ai/api/v1/process \
2 -H "Authorization: Bearer li_live_abc123..." \
3 -F "files[]=@loan_application.pdf" \
4 -F "files[]=@bank_statements.pdf" \
5 -F "files[]=@rent_roll.xlsx" \
6 -F "propertyAddress=123 Easy St, Austin, TX 78701"

First request

Start with one package and the real async contract.

The first-run lane is intentionally narrow: create the account, create the key, submit the package, then retrieve JSON and PDF with the returned job credentials. That keeps activation proof simple for a developer evaluating fit.

Queued response
{
  "success": true,
  "jobId": "job_abc123",
  "requestId": "job_abc123",
  "accessToken": "eyJhbGciOiJIUzI1NiIs...",
  "retrievalToken": "eyJhbGciOiJIUzI1NiIs...",
  "customerKey": "Rq7xK...",
  "status": "queued",
  "statusUrl": "https://api.loanintelligence.ai/api/v1/jobs/job_abc123",
  "downloadUrl": "https://api.loanintelligence.ai/api/v1/jobs/job_abc123/report",
  "estimatedCompletion": "2026-03-16T15:05:05.000Z",
  "expiresAt": "2026-03-18T15:04:05.000Z",
  "security": {
    "encrypted": true,
    "algorithm": "aes-256-gcm",
    "warning": "Save your customerKey securely. It cannot be recovered later."
  },
  "timestamp": "2026-03-16T15:04:05.000Z"
}

What a developer proves on day one

  • The API plan lane is separate from the dashboard-only policy editor flow.
  • statusUrl, accessToken, and customerKey are the retrieval contract to persist.
  • The same completed job can yield both dashboard.json and the PDF report.
Poll completed job
1curl https://api.loanintelligence.ai/api/v1/jobs/job_abc123 \
2 -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." \
3 -H "X-Customer-Key: Rq7xK..."
Download PDF report
1curl https://api.loanintelligence.ai/api/v1/jobs/job_abc123/report \
2 -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." \
3 -H "X-Customer-Key: Rq7xK..." \
4 --output report.pdf
Completed job payload
{
  "jobId": "job_abc123",
  "requestId": "job_abc123",
  "status": "completed",
  "statusUrl": "https://api.loanintelligence.ai/api/v1/jobs/job_abc123",
  "downloadUrl": "https://api.loanintelligence.ai/api/v1/jobs/job_abc123/report",
  "accessToken": "eyJhbGciOiJIUzI1NiIs...",
  "report": {
    "onDemand": true,
    "ready": true,
    "downloadUrl": "https://api.loanintelligence.ai/api/v1/jobs/job_abc123/report",
    "expiresAt": "2026-03-18T15:04:05.000Z"
  },
  "dashboard": {
    "loanInfo": {},
    "underwritingAssessment": {},
    "processingChecklist": {},
    "creditPolicyEvaluation": {}
  },
  "metadata": {
    "documentsProcessed": 12,
    "activePolicies": 2,
    "policiesEvaluated": 1
  },
  "completedAt": "2026-03-16T15:04:43.000Z"
}

Policy management

Treat stored credit policies as an inspectable, versioned API surface.

Once an API customer has a working first request, they can manage stored policies directly over API key auth: list what is on the account, inspect source and spec hashes, import a new policy, replace the strict canonical spec, reextract from fresh source, and control which stored policy is active or selected at runtime.

List stored policies
1curl https://api.loanintelligence.ai/api/v1/policies \
2 -H "Authorization: Bearer li_live_abc123..."
Import a policy from raw source
1curl https://api.loanintelligence.ai/api/v1/policies \
2 -H "Authorization: Bearer li_live_abc123..." \
3 -H "Content-Type: application/json" \
4 -d '{
5 "filename": "bridge-guidelines.pdf",
6 "base64": "<base64-pdf>",
7 "isActive": true
8 }'
Policy inventory response
{
  "success": true,
  "data": [
    {
      "id": "policy_abc123",
      "lenderName": "Bridge Capital",
      "documentTitle": "Bridge DSCR Guidelines",
      "loanTypes": ["bridge", "dscr"],
      "isActive": true,
      "version": 3,
      "updatedAt": "2026-03-16T15:04:43.000Z",
      "numericRulesCount": 12,
      "eligibilityRulesCount": 4,
      "exclusionsCount": 2,
      "documentChecklistCount": 9,
      "sourceType": "custom",
      "sourceContentHash": "6b85c41d0d2d...",
      "policySpecHash": "80df4a704f3c..."
    }
  ],
  "count": 1
}
Replace the strict canonical policy spec
1curl https://api.loanintelligence.ai/api/v1/policies/policy_abc123 \
2 -X PUT \
3 -H "Authorization: Bearer li_live_abc123..." \
4 -H "Content-Type: application/json" \
5 -d '{
6 "policySpec": {
7 "metadata": {
8 "lenderName": "Bridge Capital",
9 "documentTitle": "Bridge DSCR Guidelines",
10 "loanTypes": ["bridge", "dscr"]
11 },
12 "numericRules": [
13 {
14 "id": "ltv_max",
15 "metric": "ltv",
16 "comparator": "<=",
17 "value": 75
18 }
19 ],
20 "eligibilityRules": [
21 {
22 "id": "entity_required",
23 "field": "entityType",
24 "allowedValues": ["llc", "corporation"]
25 }
26 ],
27 "documentChecklist": [
28 {
29 "id": "rent-roll",
30 "name": "Rent Roll",
31 "category": "financial",
32 "required": true
33 }
34 ]
35 }
36 }'
Reextract a stored policy in place
1curl https://api.loanintelligence.ai/api/v1/policies/policy_abc123/reextract \
2 -X POST \
3 -H "Authorization: Bearer li_live_abc123..." \
4 -H "Content-Type: application/json" \
5 -d '{
6 "filename": "bridge-guidelines-v2.pdf",
7 "base64": "<base64-pdf>"
8 }'
Activate a stored policy
1curl https://api.loanintelligence.ai/api/v1/policies/policy_abc123/active \
2 -X PATCH \
3 -H "Authorization: Bearer li_live_abc123..." \
4 -H "Content-Type: application/json" \
5 -d '{
6 "isActive": true
7 }'

Stored-policy capabilities

  • GET /api/v1/policies lists stored policies with sourceContentHash and policySpecHash.
  • POST /api/v1/policies accepts either raw source (base64 + filename) or a canonical policySpec.
  • PUT /api/v1/policies/:policyId fully replaces the canonical rule/checklist schema.
  • POST /api/v1/policies/:policyId/reextract overwrites the same stored policy id from new raw source.
  • PATCH /api/v1/policies/:policyId/active controls active billing and selectedPolicyId eligibility.
  • options.selectedPolicyId is the advanced processing override after stored policies exist.
Canonical strict policySpec
{
  "metadata": {
    "lenderName": "Bridge Capital",
    "documentTitle": "Bridge DSCR Guidelines",
    "loanTypes": ["bridge", "dscr"],
    "effectiveDate": "2026-01-15",
    "version": "2026.1"
  },
  "numericRules": [
    {
      "id": "ltv_max",
      "metric": "ltv",
      "comparator": "<=",
      "value": 75,
      "unit": "percent",
      "citation": "Section 4.1"
    }
  ],
  "eligibilityRules": [
    {
      "id": "entity_required",
      "field": "entityType",
      "allowedValues": ["llc", "corporation"]
    }
  ],
  "exclusions": [
    {
      "id": "rural_exclusion",
      "type": "market",
      "values": ["rural"]
    }
  ],
  "documentChecklist": [
    {
      "id": "rent-roll",
      "name": "Rent Roll",
      "category": "financial",
      "required": true
    }
  ]
}
Use selectedPolicyId during processing
1curl https://api.loanintelligence.ai/api/v1/process \
2 -H "Authorization: Bearer li_live_abc123..." \
3 -F "files[]=@loan_application.pdf" \
4 -F "files[]=@rent_roll.xlsx" \
5 -F 'options={"selectedPolicyId":"policy_abc123"}' \
6 -F "propertyAddress=123 Easy St, Austin, TX 78701"

Package economics

Price the workflow like a lending operation, not a token experiment.

  • Pricing is intended to map to real package economics rather than token-metered AI abstractions.
  • Policy units track the active stored policy set on the account for that package, not just the single policy ultimately selected.
  • Hash reuse prevents duplicate stored policy versions when the same source or canonical spec is submitted again.

Boundaries

Clear lines around retention, governance, and decision ownership.

  • Loan documents are processed ephemerally in the API lane.
  • Stored credit policies remain available on the account so teams can list, inspect, and reuse them.
  • Deterministic calculations stay machine-readable for downstream systems.
  • The platform does not make the credit decision for you. Human judgment and policy governance remain with your team.
POST/api/v1/process

Submit a loan package

Queues a package, returns retrieval credentials, and gives you a stable async contract for dashboard.json plus PDF retrieval.

First-run lane: use this before any policy management. It is the cleanest proof that an account, API key, and retrieval contract all work end to end.

Key error states

  • MISSING_FILES: No supported loan package files were submitted.
  • INVALID_OPTIONS: The options payload is not valid JSON or conflicts with the selected policy settings.
  • INVALID_SELECTED_POLICY_ID: The supplied selectedPolicyId is empty or not usable with stored policies disabled.
  • MISSING_CUSTOMER_KEY: Completed results require the original customerKey returned at job creation time.
  • INVALID_POLICY_SPEC: Policy management requests must use the strict canonical schema.
  • POLICY_EXTRACTION_FAILED: A raw policy document could not be extracted into a canonical stored policy.

Reference client

Keep the first integration honest in code.

Node.js async polling example
import fs from 'node:fs';
import axios from 'axios';
import FormData from 'form-data';

const form = new FormData();
form.append('files[]', fs.createReadStream('loan_application.pdf'));
form.append('files[]', fs.createReadStream('rent_roll.xlsx'));
form.append('propertyAddress', '123 Easy St, Austin, TX 78701');

const submit = await axios.post(
  'https://api.loanintelligence.ai/api/v1/process',
  form,
  {
    headers: {
      Authorization: 'Bearer li_live_abc123...',
      ...form.getHeaders(),
    },
  }
);

const { statusUrl, accessToken, customerKey } = submit.data;

let job;
do {
  await new Promise((resolve) => setTimeout(resolve, 3000));
  const status = await axios.get(statusUrl, {
    headers: {
      Authorization: `Bearer ${accessToken}`,
      'X-Customer-Key': customerKey,
    },
  });
  job = status.data;
} while (job.status === 'queued' || job.status === 'processing');

console.log(job.dashboard);

Next step

Watch the proof, then start the integration.

Use the demo to understand product fit. Use the API plan when you want to prove the first package, then the stored-policy workflow, against a real developer account.