Consents & contact details

The expensive mistake in customer contact is treating one fact as though it were another: calling because a number is verified, texting because some consent exists, contacting at all because nobody wrote “do not call” anywhere obvious. Each of those is a different question with its own record, and the platform keeps them apart so that a contact made a year ago can still be explained rather than reconstructed.

Verification comes from integrations, not callers

A contact detail is EMAIL or PHONE; contactType is immutable. Phones carry a phoneType of MOBILE, LANDLINE, VOIP, or UNKNOWN—a provider fact with a source, not a guess based on number format. A number pattern that looks mobile and is not is how an autodialer reaches a landline nobody consented to reach. Mutations go through POST /v1/customers/{customerId}/contact-points and PUT/DELETE on /v1/customers/{customerId}/contact-points/{contactPointId} (UPDATE_LMS_CUSTOMER_CONTACT); current state is read from the customer record, which masks the stored values.

Texting permission lives on the phone

canReceiveSms is the explicit texting permission for one phone contact detail—not a consent record. It defaults to false and every change must carry smsPermissionChangedAt:

curl -X PUT "$BASE/v1/customers/412/contact-points/513" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: maya-sms-stop-1" \
  -d '{
    "canReceiveSms": false,
    "smsPermissionChangedAt": "2027-05-01T10:32:00-07:00"
  }'

{ "resourceId": 513, "changes": { "canReceiveSms": false } }

Changing a phone’s value resets canReceiveSms and verification state unless fresh trusted results arrive in the same change—permission attaches to a number, not to whatever number happens to occupy the slot. Without the reset, a permission granted by the person who held the old number would be spent on a stranger who now holds the new one.

A grant is immutable; revocation closes it

Consents come from a fixed list of four regulated types: ELECTRONIC_COMMUNICATION, AUTODIALED_CALL, ARTIFICIAL_VOICE, and UNUSUAL_TIME. The record captures that the permission was granted, when, how, and with what evidence—and then never changes, because the question asked afterwards is what the customer agreed to on a particular day, and an edited record cannot answer it. There is deliberately no channel or purpose scoping here: narrowing a grant at capture time would move the eligibility decision months away from the moment it has to be made.

curl -X POST "$BASE/v1/customers/412/consents" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: maya-autodial-consent-v1" \
  -d '{
    "consentType": "AUTODIALED_CALL",
    "capturedAt": "2026-08-01T17:05:00Z",
    "captureMethod": "BORROWER_PORTAL",
    "evidenceRef": "evd_CONSENT_41"
  }'

{ "resourceId": 71 }

Requires UPDATE_LMS_CUSTOMER_CONSENT. captureMethod records how the grant was obtained: STAFF_ATTESTED, BORROWER_PORTAL, E_SIGNATURE, RECORDED_CALL, IMPORT, SERVICING_WORKSPACE, or PROVIDER.

GRANTED ── bodyless revoke ──► REVOKED

Revocation takes no request body; the server derives the effective time, and the original grant and its evidence remain immutable in history. A later grant creates a new consent record with new evidence; it does not reopen the old record.

curl -X POST "$BASE/v1/customers/412/consents/71/revoke" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Idempotency-Key: revoke-consent-71"

{ "resourceId": 71 }

Consent evidence references are visible only on the audited sensitive read (GET /v1/customers/{customerId}/sensitive); the customer read shows the consent’s type, status, capture time, and method. Routing evidence through the audited read means anyone who opens the recording of a consent call is recorded as having opened it—which is the difference between evidence and a file everyone can browse.

Payment authorization is separate

An electronic-payment authorization is not interchangeable with a communication consent. One-time payments and autopay enrollments carry their own authorizationRef evidence and terms. The CFPB’s preauthorized electronic transfer rule is a useful primary reference; your counsel-approved policy determines the exact journey and evidence for each rail.

The decision is made at execution time

The Lending Core owns contact and consent facts. The Servicing Workspace combines them with local time, purpose, debt, contact frequency, representation, bankruptcy, cease, litigation, vulnerability, and jurisdiction immediately before execution. Deciding any earlier would mean acting on an answer that was true when a campaign was assembled and false by the time it dialled. See Consent & contact eligibility.