Self-service API

Everything the white-label apps do, they do through the self-service API — a borrower-scoped surface with its own authentication, its own rate limits, and none of the operator API’s authority. Build your own borrower experience on it, embed pieces of it in an existing app, or run the shipped apps unmodified; the contract is the same.

It is a separate service with its own origin: the routes below share the /v1 prefix with the operator API and nothing else.

borrower session

Self-service API

• Its own origin, its own /v1 paths
• Answers inside one borrower’s session
• Short-lived signed tokens, step-up on sensitive acts

machine client

Operator API

• Lending Core and Servicing Workspace
• Names a tenant and an exact permission
• OAuth client credentials from a backend

Thirteen resources, and one of them is staff-only

Twelve answer inside a single borrower’s session; /v1/admin is scoped to staff rather than widened for them:

Resource	What it does
/v1/auth	Password sign-in with account invitations, reset, and one-time-code step-up for sensitive operations.
/v1/me	The signed-in borrower’s profile, preferences, and security state.
/v1/loans/{loanRef}	The borrower’s view of a loan: balances, schedule, activity, statements.
/v1/loans/{loanRef}/payments	One-time payments with explicit authorization and idempotent submission.
/v1/loans/{loanRef}/autopay	Enrollment, amendment, and cancellation with the required advance-notice acknowledgements.
/v1/payment-methods	Bank and card instruments: add, verify, set default, remove.
/v1/agreements	Agreements to review and sign — the e-sign ceremony’s summary, acknowledgements, digest-bound signature, and a lasting evidence record.
/v1/conversations	Message threads with the servicing team; creates real interactions on the borrower’s case.
/v1/documents	Statements and letters to download; secure upload against document requests.
/v1/notifications	Delivery preferences and the notification feed.
/v1/assistance-requests	Structured hardship and payment-help intake that opens a servicing case.
/v1/tenant	The tenant’s branding, feature, and configuration surface the apps render from.
/v1/admin	Staff-scoped operations: conversation handling and read-only borrower masquerade grants.

Borrower-scoped by construction

A self-service session can only ever be one borrower. Sensitive fields are encrypted at rest, and a session left open on a shared laptop cannot attach a bank account or sign an agreement without a fresh one-time code; rate limits assume the internet, not an office, because this traffic arrives from phones on hotel wifi rather than one datacentre you can throttle at the source. The API exposes borrower-safe projections, never operator reads: no permission flag here unlocks another customer’s data, because no route can express the request.

Wired into servicing, not bolted beside it

The self-service surface is a front door to the same servicing workspace operators work in. A message becomes an interaction on a case and reaches the communications agent through the queues, and a person when it needs one. An assistance request opens a hardship case with its workflow, evidence requirements, and policy checks. An uploaded document lands with the document agent against the step that requested it. Portal activity that servicing should know about — sign-ins, failures, abandoned payments — flows through named portal signals rather than analytics guesswork. Nothing a borrower does in the portal is invisible to the case that serves them.

A network blip cannot double-pay

Payments are idempotent under caller-minted keys reused across retries, so the retry and the original arrive as one intent rather than two. Agreement signatures bind to the exact document digest the borrower saw, with the acknowledgement trail preserved as evidence, so a later dispute is argued from the document that was actually on screen. Money facts come from the authoritative core on every read: a cached balance is a number that used to be true, shown to the one person about to act on it. And failure states are named — a payment hold, a stale agreement, an unavailable core each return a specific machine-readable condition your UI can render honestly.