Skip to main content
Lender serves one HTTP API. Every operation sits under the base path /api/v1, and nothing versions in the host. A product list is GET /api/v1/loan-products. This page is the map, not the territory. It covers what the operations share, then groups them by the job they do. Each operation has its own page under the Lender anchor in the API Reference, with full request and response shapes.
The OpenAPI documents in this portal are render sources for the reference pages. They are not client contracts, and they are not a basis for SDK generation.

​
Authentication

Lender accepts a JWT bearer token. One security scheme applies to the whole document:
Two reads are public and take no token: list jurisdictions and get a jurisdiction. The registry is deployment metadata, so a client can read it before it has an identity. The probes stay outside authentication so an orchestrator reaches them without a token: /health, /readyz, and /version.

​
Authorization

Lender authorizes each request against the lender application, a resource, and an action. The resource follows the surface, and the actions are granular rather than one write: Grant the officer role only the actions its job needs. make generate-casdoor writes Lender’s roles and permissions to a seed file you load into your identity provider — Prerequisites shows the minimum set for origination.

​
Tenant and officer identity

The tenant is never a header, a query parameter, or a body field. Lender resolves it from the validated identity on the request. See Multi-tenancy. The assigned officer comes from the token subject in the same way. No loan-application body carries an officer field, and no client-supplied value overrides the subject.

​
Requests and responses

Every operation that carries a body sends and returns application/json. Send every money and rate field as a decimal string, never as a JSON number — "50000.00", "0.01500000". Lender returns them the same way. Timestamps are RFC 3339 in UTC.

​
Idempotency

The money and schedule writes accept an X-Idempotency request header. Send your own key. The five operations that require X-Idempotency share one behaviour:
  • A retry of a completed call replays the first response and stamps X-Idempotency-Replayed: true on it. Nothing is recorded a second time.
  • A retry while the first call is still in flight answers 409.
  • The key is scoped to your tenant and expires after the window IDEMPOTENCY_RETRY_WINDOW_SEC sets, which defaults to 300 seconds.
Repayment and reversal work differently. Both read X-Request-ID first and fall back to X-Idempotency when it is absent. Send one of the two: a call that carries neither answers 422. Lender stores the request id in the database together with the facts of the call. A retry that carries the same id and the same facts replays the first response on the normal response path, with no replay header. The same request id with different facts answers 409 rather than replaying, so one id can never record two different amounts. That record does not expire. The facts Lender compares differ by operation:

​
Pagination

Paging is per operation, not global. Read the reference page for the operation you call, and send only the parameters it declares. A value outside the range is rejected rather than clamped. Every other read declares its own parameters, so narrow it with the identifiers and filters on its reference page.

​
Errors

Every error answers application/problem+json and follows RFC 9457. Branch on the status and, for a 422, on the location values in errors. A 422 names each field that failed. A server-side failure answers with a generic detail, so a raw cause never reaches a client.

​
The operations by job

​
Catalogue a product

Eight operations own the catalog. Create a product and append a version build the terms an application binds to. The version is immutable. Bind an accounting profile maps each accounting event onto general-ledger accounts, and Lender needs it at disbursement. Apply a charge and read floating rates complete the surface, alongside list, get, and activate. Read Define a loan product.

​
Originate

Six operations carry an application from submitted to disbursed: create, then one of approve, reject, or withdraw, then disburse. Preview a schedule computes installments for a quote and persists nothing. The create and decide responses are the only reads of an application, so keep the body each call returns. Read How origination works for the state machine and Quick start for the six calls end to end.

​
Service a live loan

Five reads describe the account: the account, its schedule, its transactions, its charges, and its audit history. Five writes move money or the schedule: preview a repayment before you record it, prepay, reschedule, and reverse a transaction. Nothing rewrites history. A reversal posts a new transaction that compensates the original. Read Service a loan.

​
Account and book

Start an accrual run recognizes interest for a competence period. List journal references by correlation id and read one to find the accounting record a run wrote. Read Accounting and accrual runs.

​
Discover jurisdictions

The two public reads report which jurisdiction codes this deployment carries and what each profile decides. Read Jurisdictions.

​
Brazil

The Brazil pack adds regulated reads and writes under /api/v1/br: CET disclosure, the credit-operation descriptor, PDD stage and its transitions, a prepayment quote with its payoff statement, tax preview, and capitalization consent. The pack also carries its own product paths, which behave like the generic ones under Brazilian rules. Read Brazil regulatory pack. The payroll-deducted journey is an event conversation with the payroll rail, not a set of REST calls. Read Consignado privado.

​
Next steps

Quick start

Six calls from an empty database to a disbursed loan.

Events

Subscribe to the credit journey instead of polling.

API Reference

Every operation, with full request and response shapes.

Prerequisites

The services, migrations, and configuration a first call needs.