> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amlok.io/llms.txt
> Use this file to discover all available pages before exploring further.

# API surface review

> Findings from the complete 192-operation contract and the proposed 45-operation replacement.

Reviewed **November 6, 2026** against the complete generated OpenAPI contract, all 192 operations, request and response schemas, API guides, normalized resource dictionary, derived attributes, integration coverage, SDK generation and billing rules in the documentation repository. The original source workbook remains unchanged.

## Finding

The public boundary follows internal data collections and processing stages more closely than the customer's two product journeys. The problem is not that the underlying data model is too detailed. Financial institutions need that evidence. The problem is making every collection and execution stage a separate integration concern.

The proposed replacement has **45 operations**, 147 fewer than the current 192 (about **77% fewer**). This is a target contract, not a claim that backend endpoints have been retired.

## What needs to change

| Finding | Current evidence | Design change |
| - | - | - |
| Underwriting requires orchestration knowledge | Create application, discover a manifest, choose workflow version and input IDs, start workflow, resolve separate decision, attributes and snapshot | One Origination submission; AMLOK owns orchestration and returns a risk package |
| No first-class risk package | `RiskSnapshot` links attributes, manifest and workflow; `Decision` is a separate artifact | One immutable result with dimensions, policy evaluations, versioned input context and evidence links |
| Lending product catalog is missing | `/v1/products` represents inventory items; application creation supplies only product type and limited requested terms | Explicit immutable lending-product versions, including pricing and repayment terms |
| Policy input is incomplete | Decisions report policy IDs, but the public contract has no complete policy ingestion/version resource | Versioned validated risk policies supplied or provisioned before underwriting; no arbitrary executable policy code |
| Borrower embedding lifecycle is missing | Connection authorization exists, but no institution-facing embedding-session resource is documented | Short-lived, borrower-bound sessions tied to a published Integrations Hub configuration |
| Data access is fragmented | 96 operations can be expressed as evidence reads without losing their typed records | One paginated evidence collection and exact-version record reads, plus exports and controlled file downloads |
| Internal processing leaks into client code | 26 operations expose job, manifest, baseline or included-stage responsibilities | Keep these internal; expose requirements, useful status, workload reporting and traceability |
| Monitoring is too technical at enrollment | Monitor creation needs a baseline snapshot, resource types, attribute keys, cadence and ruleset | Accept funded-deal context and approved policy; resolve the baseline and source scope internally |
| Events, risk conditions and delivery can be confused | Separate webhook, alert, change-feed and job families | Keep business alerts, durable events and HTTP delivery attempts distinct, with clear links |
| Financial reporting repeats retrieval patterns | 20 billing operations plus 2 workload reads | Read-only summary, immutable transactions and typed exports; preserve all financial detail |

## Disposition of every current operation

| Disposition | Operations | Meaning |
| - | -: | - |
| Retain a customer capability | 13 | Monitoring controls, alerts, connection visibility, recovery and reliability |
| Consolidate | 52 | Combine related reads and inputs into product resources |
| Expose through evidence | 96 | Preserve normalized records and source versions behind unified retrieval |
| Internalize execution | 26 | AMLOK owns collection, included checks, calculations, manifests and orchestration |
| Manage in the console or test tooling | 5 | Webhook administration, organization audit logs and sandbox controls |

Download the [complete 192-operation migration inventory](https://docs.amlok.io/downloads/api-endpoint-migration.csv). Each row includes the stable v1 operation ID, method, path, disposition, destination and reason. No endpoint is dropped from the inventory.

## What should stay

* The typed normalized dictionary and field provenance. Fewer routes must not mean untyped financial blobs.
* Immutable assessment inputs, outputs and evidence versions; no product-data update or delete commands.
* Explicit missing, stale, restricted and not-applicable states. Missing values do not become zero or a passing policy result.
* Workspace and environment isolation, source entitlements, audited downloads, idempotency and accepted-command recovery.
* Included KYB/KYC, lien, calculation and investigation stages within Insights or Signal, without new standalone product charges.
* The existing shared-wallet, funding, cancellation, refund and Signal account-month rules. This review does not change pricing or commercial terms.

## Design basis

The report-oriented flow is consistent with [Plaid's Assets pattern](https://plaid.com/docs/assets/): request a report, receive completion notification and retrieve the result. That is an API design reference, not an assertion of equivalent product coverage or licensing. [Stripe's response expansion](https://docs.stripe.com/api/expanding_objects) also illustrates returning related context together instead of requiring a separate request for every object. AMLOK's design uses bounded summaries with paginated evidence rather than unbounded expansion.

For assessment content, [OCC small-business lending guidance](https://www.occ.gov/topics/supervision-and-examination/credit/commercial-credit/small-business-lending.html) emphasizes repayment capacity and current and expected cash flows. [OCC retail lending guidance](https://occ.gov/publications-and-resources/publications/comptrollers-handbook/files/retail-lending/pub-ch-retail-lending.pdf) discusses consumer capacity measures. These inform the dimension taxonomy; they do not establish universal thresholds or certify AMLOK compliance. Business and consumer methods, populations and permitted data must be validated separately.

## Delivery boundary

This repository deploys documentation. It does not contain the product processing backend. The changes publish a smaller, schema-defined design, a clearer entry point and a migration plan while keeping v1.4.2, its operation IDs, source snapshot, SDK inputs and examples intact.

The implementation gates and cutover sequence are in [Migration and release gates](https://docs.amlok.io/api-reference/product-api-migration.md). Backend behavior, live provider access, payment execution and production underwriting accuracy are not verified by documentation tests.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.