Quickstart

Choose an adoption path

LendEasy exposes one public contract: the LendEasy Lending Core and the Servicing Plane that runs natively on it — adoptable together or separately, with a bring-your-own-core binding on the roadmap as an additional deployment option:

The examples below use fictional Sandbox data from the example product portfolio. Monetary representations follow each operation schema: current servicing money fields use an { amount, currency } object, while Lending Core operations use their declared string or numeric form.

1. Exchange client credentials

Credentials are isolated by environment. Exchange the Sandbox client ID and secret from a trusted backend; never put the secret in a browser or mobile application.

export BASE=https://sandbox.api.lendeasy.ai
export CLIENT_ID=your_sandbox_client_id
export CLIENT_SECRET=your_sandbox_client_secret

export TOKEN=$(curl --silent https://auth.lendeasy.ai/oauth2/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "scope=lending:read lending:write servicing:read servicing:write" \
  | jq -r .access_token)

Tokens are short-lived and environment-specific. Cache a token until shortly before its expires_in window ends; do not request one for every API call. Every API call also names its tenant with the LendEasy-Tenant header — the Sandbox examples use demo-lender.

2A. Full platform: create Maya’s customer record

Create the customer aggregate with its first residence and contact point in one request. The Idempotency-Key is optional; sending one lets a retry return the original result instead of creating a second record.

curl -X POST "$BASE/v1/customers" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: customer-crm-person-81042" \
  -d '{
    "profile": {
      "customerType": "INDIVIDUAL",
      "firstName": "Maya",
      "lastName": "Chen",
      "dateOfBirth": "1991-11-04",
      "externalId": "crm-person-81042"
    },
    "addresses": [{
      "addressType": "PRIMARY_RESIDENCE",
      "line1": "428 Alder Way",
      "city": "Sacramento",
      "stateCode": "US-CA",
      "postalCode": "95814",
      "country": "US",
      "isPrimary": true
    }],
    "contactPoints": [{
      "contactType": "EMAIL",
      "value": "maya.chen@example.test",
      "isPrimary": true
    }]
  }'

{
  "resourceId": 412
}

Mutations return this command envelope; read GET /v1/customers/412 for the full aggregate — the profile plus its current addresses, masked contact points, consents, and masked identifiers. Keep the customer ID (it serializes as the string "412" on reads) as the relationship key used by loans, instruments, and restrictions, and use externalId to correlate with your own application or CRM. Next, follow Originate a loan.

2B. Servicing Plane: open a case

The implemented Servicing Plane uses numeric record IDs and stable string references. Create a collections matter from an authoritative signal:

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

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

Continue with API availability for the current task, interaction, governed-operation, and evidence routes.

2C. Roadmap: bring your own core

If your core owns the customer and loan, create a binding rather than duplicating them. The binding declares the protocol and freshness budget; the next calls publish capabilities and create explicit identity mappings.

curl -X POST "$BASE/v1/servicing/core-bindings" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: core-binding-orbit-v1" \
  -d '{
    "name": "Orbit servicing ledger",
    "protocol": "https_json_v1",
    "baseUrl": "https://servicing-core.example.test/lendeasy",
    "authenticationProfileId": "auth_orbit_mtls_1",
    "freshnessPolicy": {
      "balancesSeconds": 30,
      "delinquencySeconds": 60,
      "restrictionsSeconds": 10
    }
  }'

The response returns a bindingId. Continue with the Bring your own system of record readiness sequence before opening production cases.

Confirm the integration contract

Before building a workflow, verify these invariants:

• every ordinary implemented call carries the LendEasy-Tenant header; Idempotency-Key is optional but recommended on current Lending Core and implemented servicing mutations (1–50 characters), and a replay returns the original result with x-served-from-cache: true;
• every money amount carries an ISO 4217 currency — decimal strings on LendEasy-owned resources, decimal numbers on native loan routes;
• every effective business date is distinct from its processing timestamp;
• Lending Core IDs are numeric (customer 412, loan 7204; customerId and loanRef serialize as strings); current Servicing Plane record IDs are also numeric, while stable external references such as externalCaseRef, customerRef, loanRef, and effectRef remain strings;
• a 409 is resolved by reading current state — or by waiting Retry-After when the same request is still in flight — never by blind retry;
• a governed command can park under maker-checker, where a different checker approves it before it executes.