Postman collection

The collection exists so you can try a call before you write the code for it. It is generated from the same OpenAPI document as the API reference, which keeps it from drifting away from the API it describes — a hand-maintained collection is a copy of the API as somebody understood it on the day they saved it, and it disagrees with the real one long before anybody notices.

Six files, one generated contract

• LendEasy v1 Postman collection
• Sandbox environment
• Production environment
• Combined OpenAPI 3.1 contract
• Implemented servicing client OpenAPI
• Implemented servicing connector OpenAPI

Servicing request names end in [Implemented] or [Future-facing], so product-direction APIs sit in the same workspace without looking like current runtime routes. The label is on the request rather than in a separate list, because a folder note is not read at the moment somebody presses Send.

Five steps to an authorized environment

Ordinary client requests inherit Authorization: Bearer {{token}} and LendEasy-Tenant: {{tenant}}. Mutating requests carry Idempotency-Key: {{$guid}}; replace the GUID with a stable 1–50 character operation key when testing replay on the Lending Core or implemented servicing. A fresh GUID on every send is a fresh intent, so the replay you meant to test never happens: the second send creates a second record instead of returning the first. Future-facing operations keep their own documented key constraints.

Connector callbacks override the collection bearer setup: channel events send gatewaySignature as X-LendEasy-Gateway-Signature, and voice callbacks send the dispatch-bound dispatchToken as X-LendEasy-Voice-Task-Token. Those values come from the configured connector journey, not a human OAuth session.

The environment carries every value that varies

Nothing that varies between environments is written into a request, so pointing the collection at a different environment is one selector change rather than an edit pass over every saved URL. Postman scripts can save IDs from create responses, but the collection never silently changes Production variables.

Seven requests that prove the wiring

Run these in order: they exercise credentials, idempotency, lifecycle state, and money simulation — the four things that fail differently and are worth failing early:

1. Customers → Create a customer; resend with the same key and confirm the replay returns the original result with x-served-from-cache: true.
2. Loans → Create a loan application with command=calculateLoanSchedule; inspect every installment and totals without persisting anything.
3. Loans → Create a loan application (no command), then Retrieve a loan with associations=repaymentSchedule.
4. Loans → Retrieve a loan summary; compare its payoff projection and APR disclosure blocks with the guides.
5. Cases → Create a case [Implemented], then Retrieve a case workspace [Implemented] and inspect its tasks and allowed actions.
6. Tasks → Reserve the next eligible task [Implemented]; use a stable key and confirm the reservation belongs to the authenticated worker.
7. Servicing reports → Read the compliance report [Implemented]; confirm the focused report is visible with the expected permission.

Share the collection, never the credentials

Exported environments omit current secret values. Keep credentials in a personal environment or your secrets manager: a credential in a synced team workspace is held by everyone who ever joins it, including after they leave. Use a separate OAuth client for automated tests so it can be rotated or revoked without affecting applications.