Dates & timestamps

The API deliberately uses both calendar dates and timestamps. Converting one into the other in client code changes meaning.

Representations

Preserve offsets as supplied. Normalize to UTC for storage if desired, but retain the original customer-local or policy-local context needed for explanation.

Native wire format

The native loan and accounting routes add two conventions of their own:

• Requests carry dateFormat and locale alongside every date, and the dates must match that format: { "submittedOnDate": "2026-08-11", "dateFormat": "yyyy-MM-dd", "locale": "en" }.
• Responses serialize dates as [year, month, day] arrays — a schedule period’s due date arrives as "dueDate": [2026, 9, 12].

LendEasy-owned resources — customers, payments, fundings, statements, the loan summary — use plain ISO strings in both directions and never require dateFormat or locale. Map the array form to a date-only value at your integration boundary; do not paste the array into a timestamp constructor.

Effective date is not posting time

Harbor payment 1 is effective September 12 and posts after ACH settlement on September 15:

{
  "paymentId": 9011,
  "effectiveDate": "2026-09-12",
  "timeline": [
    { "occurredAt": "2026-09-15T14:22:08Z", "source": "LMS", "state": "POSTED", "postedTransactionRef": "30411" }
  ]
}

Allocation, accrual, delinquency, and the next schedule state use the approved effectiveDate — posting is value-dated back to it, and a future effective date posts on that business date. Operational latency and reconciliation use the timeline’s posting instant. The system does not disguise settlement delay by rewriting either field.

Funding date

An expected disbursement date is proposal input. Interest begins from the actual effective disbursement established when the payout settles and posts under product policy. Approval or provider acceptance alone does not establish the loan balance.

Source freshness

Bring-your-own-core facts carry both:

{
  "name": "loan.amountPastDue",
  "value": { "amount": "517.14", "currency": "USD" },
  "asOf": "2027-05-01T10:11:56-07:00",
  "observedAt": "2027-05-01T10:11:57-07:00",
  "freshness": "fresh"
}

asOf measures source truth; observedAt measures integration latency. A recently observed old fact is still old.

Customer-local policy

Contact eligibility resolves the customer’s applicable local time from approved facts and records the time zone and rule version. Daylight-saving gaps and repeats are handled by a named scheduling policy. Never compare the operator’s local clock to a customer contact window.

Date-only parsing

Do not parse 2026-09-12 into midnight UTC and then render it in a negative offset—it may become September 11. Treat business dates as date-only values through your stack, whether they arrive as ISO strings or as native [year, month, day] arrays.

Closed periods and corrections

Backdated financial actions validate permitted effective windows, locked statements, accounting periods, and schedule dependencies. A permitted correction creates explicit reversal/reprocessing records; it does not edit historical timestamps.

Payoff windows

The loan summary’s payoff block is a projection computed for payoffGoodThroughDate — the current business date when omitted. goodThroughDate identifies the calculation horizon, quotedAt records when it was computed, and validUntil bounds how long the figures may be used. Nothing is stored: if collection will be effective after the good-through date, re-read the summary with a later date rather than appending client-calculated per diem.