API availability

Every other guide on this site describes the product. This one is measured, not described — the counts below come from the build’s own route manifests, and where the manifest and the running code disagree, this page says so.

Servicing operations by area

The Lending Core carries its own 214

The LendEasy Lending Core registers 214 operations under /v1 in the same combined manifest, measured the same way — customers, identities, forms, notes, documents, consents, payment instruments, loan products, loans and schedules, payments, autopay, funding, statements, accounting, charges, restrictions, reconciliation, and reporting. Twelve of those routes are governed command endpoints running under case governance and native maker-checker, carrying 30 distinct commands — disbursement, repayment, charge-off, write-off, re-age, re-amortize, contract termination, the refund family, and their audited undo counterparts among them. A further set of engine-native administration routes deliberately stays outside the documented public contract and is blocked by default in the composed platform; the API reference documents the curated surface.

One tenant header, and IDs that mean what they say

Ordinary client operations use the shared API origin and require exactly one LendEasy-Tenant header. Servicing record IDs such as caseId, taskId, interactionId, and promiseId are positive numeric IDs. Stable external references such as externalCaseRef, customerRef, loanRef, and effectRef remain strings.

Idempotency-Key is optional on servicing mutations and may be 1–50 characters. Supplying a valid key opts the request into replay protection; omitting it gives that received attempt a fresh server-owned key. Connector callbacks instead use their signed gateway event identity or dispatch-bound token.

curl -X POST "$BASE/v1/servicing/cases" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Idempotency-Key: collections-event-789" \
  -H "Content-Type: application/json" \
  -d '{
    "customerRef": "412",
    "caseTypeCode": "COLLECTIONS",
    "reasonCode": "DELINQUENCY_SIGNAL",
    "priority": "HIGH",
    "loanRefs": ["7204"],
    "sourceType": "LMS_EVENT",
    "sourceRef": "event-789"
  }'

The result separates the numeric resource ID from the stable external reference and tells the caller whether exact-source deduplication returned an existing case:

{
  "caseId": 1001,
  "externalCaseRef": "LE-CASE-1001",
  "status": "OPEN",
  "deduplicated": false,
  "resourceId": 1001
}

Three ways a change reaches the system that owns it

The runtime has three paths. Choosing the right one prevents a case, task, or generic approval from accidentally becoming authority.

An action request is created only when the owning operation returns APPROVAL_REQUIRED, or when execution is genuinely deferred, manual, external, or unavailable. A routine ALLOWED result executes immediately and creates no fabricated request, approver, or approval fields.

Compliance is inside the owning operation

There is no public route that asks the compliance engine for a decision. The engine runs inside the operation being attempted, on facts read at that moment. Interaction sending, borrower-facing actions, restriction changes, case transitions that need policy, AI dispatch, and voice dial authorization invoke it automatically with current authoritative facts.

This means a client cannot attach an old decision and force execution. For example, POST /v1/servicing/calls/outbound creates the interaction evidence first, evaluates policy immediately before dial, and returns the blocked or failed attempt as a 201 with its decision rather than discarding it. A scheduled callback’s start-call command runs the same gate again at dial time, however long after the window was booked. Scheduled email and SMS sends are deliberately not offered: a message composed now is sent now, under the at-send gate.

The shortest real path through a case

A current collections flow stays entirely on registered routes:

1. POST /v1/servicing/cases creates or exactly deduplicates the matter.
2. POST /v1/servicing/tasks/reserve-next reserves eligible work in one step; POST /tasks/{taskId}/accept accepts it.
3. POST /v1/servicing/calls/outbound dials under the at-dial gate; POST /cases/{caseId}/scheduled-callbacks books a promised window; POST /interactions records an inbound/external interaction.
4. POST /v1/servicing/cases/{caseId}/promises records an in-guardrail promise immediately or returns the opened approval request.
5. GET /v1/servicing/cases/{caseId}/promises, /action-requests, and /effects populate the case workspace.
6. GET /v1/servicing/cases/{caseId}/evidence-export returns the audited examination bundle.

Promise evaluation itself is servicing-owned and runs from authoritative payment events and scheduled operational jobs. It is not a caller-triggered endpoint.

A connector’s authority is never a human role

Most routes are ordinary authenticated client operations. Connector callbacks are a separate, narrower class:

• POST /v1/servicing/channel-events/{gatewayCode} uses the configured gateway’s signed event contract in X-LendEasy-Gateway-Signature.
• POST /v1/servicing/voice-dispatches/{dispatchId}/dial-authorization uses the dispatch-bound X-LendEasy-Voice-Task-Token and rechecks policy immediately before dial.
• POST /v1/servicing/voice-dispatches/{dispatchId}/disposition uses the same task-token header, accepts the closed voice-outcome contract, and maps it to idempotent servicing effects.

Connector authority is never a human role permission, and the connector cannot choose arbitrary customer, task, action, approval, or policy inputs.

The downloadable contracts:

• Servicing client OpenAPI — the published client operations, regenerated from a named route-manifest snapshot. The downloadable specs carry 257 client operations and 12 connector callbacks, regenerated from the same catalog these counts come from.
• Servicing connector OpenAPI — the externally reachable callbacks.
• Combined platform OpenAPI — published servicing operations, roadmap contracts, and the Lending Core.

Every listed row is callable

Every row in the build’s route manifest has a resource behind it: 287 listed, 287 callable. That has not always been true — three credit-reporting rows were listed here as listed, not routed until the furnishing surface was narrowed to the routes that exist, and the two reads named there now resolve.

The count on this page is derived from the manifest rather than maintained by hand, so a row that is added without a resource shows up as a divergence here rather than as a number nobody checked.

What ships, and what needs a contract first

Two lanes are complete in the platform and gated outside it. Credit-bureau furnishing is registered and callable — the profile, enrolled accounts, reviewable cycles, the generated file and the dispute path — and no file has been transmitted to a bureau, nor can be, until a furnisher agreement and per-bureau certification exist. The accounting export is the same shape: the mechanics are the platform’s, the authorization is granted per lender.

Among the external-signal sources, disaster declarations read a public federal dataset needing no credential. The other four require a commercial agreement between the lender and the data provider, and a connection stays in MISSING credential state — and so cannot be activated — until that agreement exists.

A corporate customer is screened as an entity; its officers, directors and owners are not. That is missing data rather than a missing read — the platform holds no register of company relationships to screen against — and the coverage read says so in its own claim rather than reporting a clean sweep. Screening a company’s name is not the same as screening the people behind it, and a report that blurred the two would be worse than no report.

The platform ships the lane; the lender brings the contract. The platform ships the lane; the lender brings the contract. Each lane below says which half is already in place.

Reading roadmap contracts

Some guides and reference entries describe contracts ahead of the runtime — deliberate product direction, kept in the docs so the destination is visible. The API reference badges each endpoint (x-availability in the combined OpenAPI): operations marked implemented are registered in the current build’s manifest, and operations marked future-facing are roadmap contracts that follow the same path conventions as their implemented neighbors.