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.

The surface

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 durable 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. Tokens are short-lived and signed; sensitive fields are encrypted at rest; sensitive operations — adding an instrument, signing an agreement — require step-up verification; and rate limits assume the internet, not an office. The API exposes borrower-safe projections, never operator reads: no permission flag on this surface 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 plane operators work in. A message becomes an interaction on a case and reaches a human through the queues. An assistance request opens a hardship case with its workflow, evidence requirements, and policy checks. An uploaded document lands with Docgest against the step that requested it. Portal activity that servicing should know about — sign-ins, failures, abandoned payments — flows through typed portal signals rather than analytics guesswork. Nothing a borrower does in the portal is invisible to the case that serves them.

Integrity contract

Payments are idempotent under caller-minted keys reused across retries — a network blip cannot double-pay. Agreement signatures bind to the exact document digest the borrower saw, with the acknowledgement trail preserved as evidence. Money facts come from the authoritative core on every read; the API never serves a cached balance as current. And failure states are typed — a payment hold, a stale agreement, an unavailable core each return a specific machine-readable condition your UI can render honestly.