Kita Underwriter

The Kita Platform API exposes the same three product layers as the dashboard: Kita Capture for document extraction and fraud signals, AI Credit Officer for borrower communication, and AI Underwriter for deterministic analysis, policy evaluation, and cited credit memos. A typical LOS integration does three things:

1. Write: push a borrower application and its documents in one call (POST /intake).
2. Read: poll the deterministic credit picture as extraction tightens (GET …/credit).
3. Generate: trigger and pull back the cited credit memo (POST …/memo → GET …/memo).

Processing is continuous: every accepted document immediately updates the assessment. There is no “100% complete” gate before underwriting starts.

Lender endpoints use /api/v1; the separate borrower-safe surface uses /api/borrower/v1. JSON success responses use a { "data": ... } envelope, with optional pagination. Every response includes X-Request-ID and X-Kita-API-Version; binary export routes return their native file type.

https://underwriter.kita.ai/api/v1

kita-docs-mcp exposes the core Underwriter workflow to Claude Code, Claude Desktop, and Codex: intake borrower files, upload documents, read the credit picture, generate memos, sync borrower conversations, and export workbooks or PDFs. Use the REST API or OpenAPI contract for the complete platform surface documented below.

claude mcp add kita-docs --env KITA_UNDERWRITER_API_KEY=kita_uw_xxxxxxxxxxxx -- npx -y kita-docs-mcp

Authenticate lender requests with a member-bound organization API key. Mint keys in Settings → API keys. A key looks like kita_uw_… and is shown exactly once at creation. Kita stores only a SHA-256 hash, so it cannot be recovered. Keys can expire, be rotated, or be revoked independently.

Pass the key in the Authorization header in either form:

Authorization: ApiKey kita_uw_xxxxxxxxxxxx
# or
Authorization: Bearer kita_uw_xxxxxxxxxxxx

New keys use resource-specific permissions. Scope is enforced per endpoint, then intersected with the bound member’s live role, approval authority, and per-application access. A valid key without sufficient access receives 403.

Errors use a consistent envelope and standard HTTP status codes:

{ "message": "This API key lacks the 'documents:write' scope required for this endpoint." }

Rate limits are enforced by operation category. Use Retry-After and the X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset response headers. Send your own X-Request-ID when you need end-to-end correlation.

Push a borrower and a tax return in one call, then read the credit picture. Replace the key and file path:

curl -X POST https://underwriter.kita.ai/api/v1/intake \
  -H "Authorization: ApiKey kita_uw_xxxxxxxxxxxx" \
  -F 'application={
        "business_name": "Rivera Family Bakery LLC",
        "borrower_email": "maria@riverabakery.com",
        "loan_type": "SBA 7(a)",
        "loan_amount": 250000,
        "external_ref": "LOS-44821"
      };type=application/json' \
  -F "file=@./2023_form_1120s.pdf"

{
  "data": {
    "id": "b1e7c9a4-...-...",
    "app_id": "APP-1042",
    "external_ref": "LOS-44821",
    "business_name": "Rivera Family Bakery LLC",
    "borrower_email": "maria@riverabakery.com",
    "loan_type": "SBA 7(a)",
    "loan_amount": 250000,
    "status": "submitted",
    "file_completeness": 0,
    "documents": [
      { "id": "9f2...", "doc_name": "2023_form_1120s.pdf", "status": "awaiting" }
    ]
  }
}

curl https://underwriter.kita.ai/api/v1/applications/APP-1042/credit \
  -H "Authorization: ApiKey kita_uw_xxxxxxxxxxxx"

The canonical loop a lender integration runs:

1. Intake. POST /intake with the borrower, loan terms, and document files. Pass external_ref (your LOS/loan id) so retries are idempotent.
2. Wait for extraction. Each document moves awaiting → processing → verified (or low_confidence). Poll GET …/documents or a single GET …/documents/{docId}.
3. Read the assessment. GET …/credit returns the spread (adjusted EBITDA/DSCR/ratios with per-metric provenance), the normalization adjustments, and the policy decision. It tightens as more documents land.
4. Generate the memo. POST …/memo synthesizes the cited credit memo, then poll GET …/memo/status until synthesis settles and read it with GET …/memo.
5. Sync back. Pull …/conversation for the borrower thread and …/export for the extraction workbook into your system of record.

Send Idempotency-Key on lender-side mutations. Synchronous mutations replay the stored response for 24 hours. Durable mutations reuse the same operation record, so a retry cannot start duplicate underwriting work. Reusing a key with a different method, path, actor, or request payload returns 409.

POST /intake also supports resource-level deduplication with external_ref, your LOS or core-banking record ID. API-key creation/rotation and webhook creation return secrets and intentionally reject Idempotency-Key.

Long-running endpoints return 202 Accepted. Durable operations include a status object and Location URL; poll that URL with operations:read. Document processing and the compatibility memo trigger are request-owned background work:

• Documents: after POST …/documents or /intake, poll a document until status leaves awaiting/processing.
• Memo: after POST …/memo, poll GET …/memo/status until synthesis_in_progress is false and is_stale is false.
• Durable work: assessment runs, provider calls, document review/reprocessing, memo generation, projections, research, normalization, decisions, and assistant requests can be polled through GET /operations/{id}.

Use exponential backoff starting around 2–3 seconds. For event-driven integrations, register a signed endpoint with POST /webhooks, inspect delivery history, and retry failed deliveries through the webhook-delivery API.

The catalog below lists all 152 operations in the current contract. The machine-readable OpenAPI 3.1 document is the source of truth for request bodies, query parameters, response codes, async behavior, and idempotency metadata.

curl https://underwriter.kita.ai/api/v1/openapi