API availability

The servicing runtime currently exposes 228 operations under /v1/servicing, and the LendEasy Lending Core registers 214 operations under /v1, both measured from the route manifests of the current build (lendeasy-core main@b60a8b2, August 2026). This page is the one place that tracks implementation truth: every other guide describes the product; this one tells you exactly what the runtime you deploy today registers.

Current surface at a glance

The Lending Core surface

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.

Common request contract

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": "123",
    "caseTypeCode": "COLLECTIONS",
    "reasonCode": "DELINQUENCY_SIGNAL",
    "priority": "HIGH",
    "loanRefs": ["456"],
    "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
}

How work crosses boundaries

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

The compliance engine is an internal application boundary, not a caller-owned public evaluation resource. 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 (DEC-2026-08-24-02): a message composed now is sent now, under the at-send gate.

Current case-work sequence

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 atomically reserves eligible work; 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 materialized 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.

Client and connector contracts

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 the current build’s route manifest.
• Servicing connector OpenAPI — the externally reachable callbacks.
• Combined platform OpenAPI — published servicing operations, roadmap contracts, and the Lending Core.

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.