> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Lender SDK and embedding
> Integrate Lender from your own software: the REST surface that carries every operation, what your client must handle for money, errors, retries and paging, and the pattern for running Lender behind a product your users already use.
**Lender's REST API is the whole client surface.** Products, applications, loan accounts, accrual runs, and the Brazilian regulatory records are all HTTP calls under `/api/v1`. Nothing exists only inside a client library.
Call Lender with the HTTP client your stack already has. There is no Lender client library to install, so the API is the contract you write against. This page covers what your client must handle and what to keep on your own side. It then covers how to place Lender behind a product your users already talk to. Read [Lender REST API](/en/lender/lender-rest-api) for the operations themselves.
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 client or SDK generation.
## What your client must handle
***
Four rules cover most of the code you write against Lender.
### Money travels as a decimal string
Every money and rate field travels as a JSON string, never as a JSON number. Money carries two decimal places, and a rate carries eight:
```json theme={null}
{
"requestedPrincipalAmount": "50000.00",
"requestedInterestRate": "0.01500000"
}
```
Send the string, and parse the string with your language's decimal type. A binary float loses cents, and a JSON number invites one. Timestamps are RFC 3339 in UTC.
### Errors answer problem+json
Every failure answers `application/problem+json`. Branch on `status`. For a `422`, read the `errors` array: each entry names the field that failed in `location`, with a `message` and the `value` Lender received. Map those locations onto your own form fields and the user sees which input to correct.
Treat `detail` as text for a person, not as a key your code matches on. A server-side failure answers with a generic detail on purpose, so no internal cause reaches a client. Log the status and your own correlation identifier, and let Lender's traces carry the rest.
### Retry the money writes with your own key
Disbursement, product charges, prepayment, reschedule, repayment, and reversal each accept an idempotency key that you generate. Derive it from your own request identifier, and a retry costs nothing.
The five operations that require `X-Idempotency` replay a completed call with `X-Idempotency-Replayed: true` on the response. They answer `409` while the first call is still in flight. Repayment and reversal key on `X-Request-ID` instead, and fall back to `X-Idempotency` when it is absent: a retry with the same facts replays, and the same id with different facts answers `409`. So branch on the response body, never on the presence of the replay header.
[Lender REST API](/en/lender/lender-rest-api#idempotency) lists which header each of those operations takes, and how long a key lives.
### Page with filters, not with deep offsets
Paging is per operation. The product list reads take `limit` and `offset`. The audit history takes `limit` alone. A value outside the declared range answers `422` rather than a quietly reduced page. Read the reference page for the operation you call, and narrow the query instead of walking a long offset.
## Keep the identifiers your writes return
***
The origination operations are commands: create, approve, reject, withdraw, and disburse. Each one answers with the full application body, and that body carries the `loanApplicationId` and, once the application is disbursed, the `loanAccountId`.
Store both on your side as you go. Your own record then links your borrower to the loan account. Every servicing read starts from an identifier you already hold, because the schedule, the transactions, the charges, and the audit history all key on the loan account.
## Embedding Lender behind your own product
***
Lender is a service you deploy, not a library you link. To put it behind an application your customers already use, keep the credentials on your side and call Lender server to server. Four rules keep that boundary clean.
**Never hand a Lender token to a browser or a mobile app**. Your service authenticates your user and decides whether that user may act. It then calls Lender with a token of its own.
**Mint the token for the person who acts**. Lender reads the assigned officer from the token subject, not from any request field. That subject is what the audit trail records, so one shared service token makes every loan look like the same officer. Lender also authorizes each transition against the officer the application is assigned to. The same subject therefore carries an application from create through to disburse.
**Hold one credential per tenant**. The tenant comes from the validated identity, never from a header, a query parameter, or a body field. In multi-tenant mode each token carries a `tenantId` claim, so your service holds one credential for every tenant it serves. Read [Multi-tenancy](/en/multi-tenancy).
**Learn about state changes from events**. Lender publishes a business event whenever a product, an application, or a loan account changes state. Subscribe and your service reacts as each change happens, with no polling loop against the servicing reads. Read [Lender events](/en/lender/lender-events).
A disbursement records its posting intent in the same database transaction that moves the application to `disbursed`, and the ledger entry lands afterwards. Do not treat a `200` on disburse as proof that the ledger already carries the entry. Read [Accounting and accrual runs](/en/lender/accounting-and-accrual-runs).
## Next steps
***
The base path, authentication, idempotency, and the operations by job.
The wire contract and the events you can subscribe to.
Six calls from an empty database to a disbursed loan.
The services, migrations, and configuration a first call needs.