Communications

An interaction is the durable operational record of attempted or completed communication. A provider event is evidence about transport. A task is work. A message body is content. Keeping them separate avoids treating “provider accepted” as “customer received” or “agent completed task” as “matter resolved.”

Channel model

Channel	Typical directions	Channel-specific evidence
Voice	inbound, outbound human, outbound AI-assisted	Dial attempts, connection, participants, recording consent, disposition.
SMS	inbound, outbound	Provider delivery, opt-out keyword, thread, segment count.
Email	inbound, outbound	Thread, message ID, bounce, attachments, delivery.
Secure message	inbound, outbound	Authenticated recipient, portal delivery, read state.
Chat	inbound customer session	Session identity, transcript, transfer, closure.
Mail	outbound, returned	Template/artifact hash, address version, handoff, return evidence.

All channels share case, customer, direction, purpose, participants, identity/authority state, sensitivity, compliance decision, content version, status, outcome, and evidence links.

Provider boundary

LendEasy interaction
  ├─ owns purpose, eligibility, content, case, and outcome
  └─ submits provider request with one correlation ID
          ↓
     provider events
       accepted → delivered / connected / bounced / failed
          ↓
     normalized timeline + reconciliation

Changing a provider does not change public interaction IDs, cases, policy, outcomes, or evidence semantics. Provider callbacks enter through closed connector contracts such as POST /v1/servicing/channel-events/{gatewayCode} with X-LendEasy-Gateway-Signature; ordinary clients use normalized interaction routes. Tenant webhook subscriptions are on the roadmap.

Outbound execution

Outbound contact either executes now, under the at-send gate, or is booked as a scheduled callback — a phone promise held as a case task carrying the exact window the borrower was given. Before invoking a provider, LendEasy re-evaluates destination, purpose, consent, local time, frequency, restrictions, debt and case state, identity/authority needs, and content policy. Scheduled email, SMS, and chat sends are deliberately not offered: a message composed now is sent now. POST /v1/servicing/interactions records an inbound, outbound, or externally completed interaction.

POST /v1/servicing/cases/1001/scheduled-callbacks

{
  "windowStart": "2027-05-01T17:00:00-07:00",
  "windowEnd": "2027-05-01T18:00:00-07:00",
  "contactPointRef": "cp_MAYA_MOBILE_1",
  "reasonCode": "COLLECTIONS_FOLLOW_UP",
  "summary": "Borrower asked for an afternoon call about the past-due installment."
}

The callback keeps its own lifecycle — reschedule, cancel, close-without-calling, start-call, and disposition — and the start-call command runs the full compliance gate again at dial time. Threaded email replies queue through POST /v1/servicing/email-threads/{threadId}/reply, each send evaluated against the loan the message is about; the thread reads under GET /v1/servicing/email-threads keep the operator inside the same governed record.

The same idempotency key can safely recover from a timeout. A new key represents a new intended attempt and may affect contact history.

For a live human dial, POST /v1/servicing/calls/outbound starts the call itself: it creates the interaction evidence first, evaluates the compliance gate immediately before dial, and only then invokes the configured telephony gateway. The response is always 201 with the persisted attempt — status is DIALING, BLOCKED, or FAILED, with the compliance decisionId and a failureCode on any non-dialing outcome. A collections call must name the case-linked loan, and the contact point must be a verified, eligible phone on the borrower profile.

Inbound signal preservation

Inbound content can contain several signals at once: a payment question, opt-out, dispute, bankruptcy mention, and attorney representation. Classification preserves every detected signal and creates or links the right matters; it does not let the apparent primary topic erase higher-risk obligations.

Content and sensitive disclosure

Templates are versioned and variables resolve from permitted facts at render time. Identity verification and authority determine which content may be disclosed. Attachments use the document boundary; raw payment credentials and restricted identifiers never enter message templates or AI context.

Outcomes

Operational outcomes are typed: blocked before send, attempted, connected, verified party reached, wrong party, delivered, bounced, opt-out, promise discussed, payment journey started, transferred, or failed. Free-text notes can add context but cannot replace the typed outcome.

See Interactions & channels for lifecycle detail and Execution-time checks for the send/dial gate.