> ## 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.
# Prerrequisitos
> Qué debe estar listo antes de tu primera llamada a Lender — los servicios de los que depende, los dos conjuntos de migraciones, la configuración que la originación exige y el token que lleva al oficial.
Lender necesita un conjunto pequeño de cosas listas antes de su primera llamada a la API. Esta página las lista en el orden en que las configuras. Cuando todo lo de aquí es verdadero, sigue el [Inicio rápido](/es/lender/lender-quick-start) para originar un préstamo.
## Servicios de los que depende Lender
***
| Servicio | Versión | Por qué Lender lo necesita |
| --------------------------------- | ------- | ---------------------------------------------------------------------------------------------------- |
| **PostgreSQL** | 17 | El almacén de datos primario. Cada producto, solicitud, cronograma e intención de posting vive aquí. |
| **Valkey** (compatible con Redis) | 8 | Registros de idempotencia, caché y rate limiting. |
| **Proveedor de identidad** | — | Emite los tokens bearer contra los que Lender autoriza cada ruta. |
| **Midaz** | — | El ledger al que llega el posting del desembolso. Opcional para tu primer préstamo. |
| **RedPanda** | — | La espina dorsal de streaming del catálogo de eventos. Opcional. |
PostgreSQL y Valkey son necesarios para originar. Un proveedor de identidad es necesario cuando la autorización de rutas está habilitada; producción lo exige. Un primer préstamo no necesita Midaz ni RedPanda. Lee [Postings en el ledger](#postings-en-el-ledger) más abajo para saber qué queda esperando.
## Ejecuta Lender en local
***
Lender es un único servicio en Go. Una ejecución local necesita el toolchain de Go en 1.26 o posterior, Docker con Compose y Make.
`make set-env` copia `config/.env.example` a `config/.env`. Edita ese archivo para cada ajuste de esta página.
`make up` arranca las dependencias de Compose y el servicio en el puerto `8080`.
`make migrate-up` aplica los dos conjuntos de migraciones. Mira la sección siguiente.
`make dev` ejecuta el servicio con Air.
## Aplica los dos conjuntos de migraciones
***
Lender no migra la base de datos cuando arranca. Aplicas las migraciones fuera de banda, y hay dos conjuntos:
| Ajuste | Valor por defecto | Contenido |
| -------------------- | -------------------------------------- | ------------------------------------------------------------------------------- |
| `MIGRATIONS_PATH` | `migrations` | El esquema central — productos, solicitudes, cronogramas, contabilidad, outbox. |
| `MIGRATIONS_BR_PATH` | `internal/jurisdictions/br/migrations` | El esquema de la jurisdicción de Brasil. |
Aplica los dos. `make migrate-up` lee ambas rutas.
El conjunto central también siembra el **registro de jurisdicciones**: dos jurisdicciones activas, `BR` para Brasil y `XX`, el perfil genérico. Ninguna API crea una jurisdicción. El binario desplegado lleva el comportamiento de cada perfil, y la tabla registra qué códigos conoce ese binario. Lee [Jurisdicciones](/es/lender/jurisdictions) para saber qué decide un perfil.
## Configuración obligatoria
***
El outbox de PostgreSQL es obligatorio y se inicializa automáticamente. Configura la autenticación cuando tu despliegue habilite la autorización de rutas.
### Un sujeto autenticado — cuando `PLUGIN_AUTH_ENABLED=true`
Lender registra quién actuó sobre cada solicitud de préstamo. Lee el **oficial asignado desde el subject del token bearer**, no desde el cuerpo de la petición. Cada llamada de solicitud de préstamo necesita entonces una identidad autenticada.
Configura tres variables:
| Variable | Valor |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PLUGIN_AUTH_ENABLED` | `true` |
| `PLUGIN_AUTH_HOST` | La dirección de tu proveedor de identidad. |
| `AUTH_REQUIRED` | `true`, para que las rutas protegidas rechacen con `503` cuando el cliente Auth está deshabilitado o mal configurado, en lugar de dejar pasar la solicitud. |
Después envía un token bearer en cada llamada. El token necesita un claim subject no vacío, y bajo el perfil genérico `XX` el mismo subject debe crear, aprobar y desembolsar la solicitud.
`make generate-casdoor` escribe los roles y permisos de Lender en `config/casdoor/init_data.json`. Carga esa semilla en tu proveedor de identidad. El rol del oficial necesita estos permisos:
| Recurso | Acciones |
| ------------------- | --------------------------------------------------- |
| `loan_product` | `write` |
| `accounting` | `write` |
| `loan_applications` | `preview:schedule`, `create`, `approve`, `disburse` |
| `loan_accounts` | `read` |
### Un destino durable para el posting — siempre presente
Un préstamo desembolsado registra su intención de posting de forma durable. Lender inicializa su outbox transaccional de PostgreSQL en cada despliegue, en la misma transacción de base de datos que mueve la solicitud a `disbursed`; `OUTBOX_ENABLED` no existe.
El despachador relaya cada intención después, con la cadencia que fija `OUTBOX_DISPATCH_INTERVAL_SEC`. Lee [Contabilidad y ejecuciones de devengo](/es/lender/accounting-and-accrual-runs) para saber qué recibe el ledger.
## Postings en el ledger
***
Apunta Lender a Midaz cuando quieras que los postings lleguen al ledger:
| Variable | Propósito |
| ------------------------------------------------- | -------------------------------------------------------- |
| `MIDAZ_LEDGER_BASE_URL` | La dirección del ledger. |
| `MIDAZ_OAUTH_TOKEN_URL` | Desde dónde Lender obtiene sus credenciales del ledger. |
| `MIDAZ_LEDGER_ORGANIZATION_ID`, `MIDAZ_LEDGER_ID` | El destino de posting por defecto en modo single-tenant. |
El préstamo se origina con o sin estas. Hasta que configures un endpoint del ledger, las intenciones de posting quedan durables en el outbox y el asiento del ledger espera. Configura el ledger antes de esperar contabilizaciones.
## Valores por defecto single-tenant
***
`MULTI_TENANT_ENABLED` es `false` por defecto. En ese modo `DEFAULT_TENANT_ID` identifica al único tenant, y debe ser un UUID válido.
## Añadidos multi-tenant
***
El modo multi-tenant da a cada tenant su propio esquema y su propio pool de clientes del ledger. Añade cuatro requisitos:
1. Configura `MULTI_TENANT_ENABLED=true` y apunta Lender al gestor de tenants.
2. Cada token lleva un claim `tenantId`.
3. `public.tenant_jurisdictions` lleva una fila por cada par de tenant y jurisdicción.
4. Cada perfil contable declara su propio `midazOrganizationId` y `midazLedgerId`. El modo multi-tenant no cae en los valores por defecto del entorno.
## Streaming de eventos
***
El streaming está apagado por defecto y la originación no lo necesita. Para publicar el catálogo de eventos del ciclo de vida, configura `STREAMING_ENABLED=true`, apunta `STREAMING_BROKERS` a RedPanda y configura `STREAMING_CLOUDEVENTS_SOURCE=lender`. Lender valida ese valor de source cuando arranca.
## Lista de verificación
***
* PostgreSQL 17 y Valkey 8 alcanzables.
* Los dos conjuntos de migraciones aplicados.
* Cuando la autorización de rutas está habilitada, `PLUGIN_AUTH_ENABLED=true`, `AUTH_REQUIRED=true`, el proveedor de identidad alcanzable y un token bearer con subject y cada permiso de la tabla de arriba.
* `DEFAULT_TENANT_ID` como UUID válido, en modo single-tenant.
## Próximos pasos
***
Seis llamadas desde una base de datos vacía hasta un préstamo desembolsado.
La forma completa del contenedor, la superficie de entorno más amplia y la ruta del posting al ledger.