Quickstart

Choose an adoption path

LendEasy exposes one public contract with two independently adoptable surfaces:

The examples below use fictional Sandbox data from the example product portfolio. Money on LendEasy-owned resources travels as decimal strings; native loan and accounting routes use decimal JSON numbers — follow each operation’s example.

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. Bring your own core: establish the contract

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 call carries the LendEasy-Tenant header; Idempotency-Key is optional but recommended on 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), while Servicing Plane records keep prefixed string IDs;
• 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.