> ## 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. # Requisitos previos > Qué debe estar listo antes de tu primera llamada a Lender: los servicios de los que depende, los dos conjuntos de migración, la configuración que requiere la originación y el token que lleva al oficial. Lender necesita un conjunto pequeño de cosas listas antes de su primera llamada de API. Esta página las lista en el orden en que las configuras. Cuando cada ítem de aquí se cumple, sigue el [Inicio rápido](/es/products/lender/lender-quick-start) para originar un préstamo. ## Servicios de los que depende Lender *** | Servicio | Versión | Por qué lo necesita Lender | | --------------------------------- | ------- | ----------------------------------------------------------------------------------------------------- | | **PostgreSQL** | 17 | El almacén de datos principal. Cada producto, solicitud, cronograma e intención de asiento vive aquí. | | **Valkey** (compatible con Redis) | 8 | Registros de idempotencia, cache y rate limit. | | **Proveedor de identidad** | — | Emite los Bearer tokens contra los que Lender autoriza cada ruta. | | **Midaz** | — | El ledger al que llega el asiento de desembolso. Opcional para tu primer préstamo. | | **RedPanda** | — | El backbone de streaming para el catálogo de eventos. Opcional. | PostgreSQL y Valkey son obligatorios para originar. Un proveedor de identidad es obligatorio cuando la autorización por ruta está habilitada. Producción lo requiere. Un primer préstamo no necesita Midaz ni RedPanda. Lee [Asientos en el ledger](#ledger-postings) más abajo para saber qué queda esperando. ## Ejecutar Lender localmente *** Lender es un solo servicio en Go. Una ejecución local necesita el toolchain de Go 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 ambos conjuntos de migración. Consulta la siguiente sección. `make dev` ejecuta el servicio con Air. ## Aplicar ambos conjuntos de migración *** Lender no migra la base de datos cuando arranca. Las migraciones las aplicas por fuera, y hay dos conjuntos: | Conjunto de migración | Directorio fijo | Contenido | | ---------------------- | -------------------------------------- | ---------------------------------------------------------------------------- | | Core | `migrations` | El esquema core — productos, solicitudes, cronogramas, contabilidad, outbox. | | Jurisdicción de Brasil | `internal/jurisdictions/br/migrations` | El esquema de la jurisdicción de Brasil. | Aplica ambos. `make migrate-up` lee ambas rutas. El conjunto core 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/products/lender/jurisdictions) para saber qué decide un perfil. ## Configuración obligatoria *** El outbox de PostgreSQL es obligatorio y se inicializa de forma automática. Configura la autenticación cuando tu despliegue habilita la autorización por ruta. ### 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 sujeto del Bearer token**, no desde el body de la solicitud. Por eso cada llamada de solicitud de préstamo necesita una identidad autenticada. Define dos variables: | Variable | Valor | | --------------------- | ------------------------------------------ | | `PLUGIN_AUTH_ENABLED` | `true` | | `PLUGIN_AUTH_HOST` | La dirección de tu proveedor de identidad. | Luego envía un Bearer token en cada llamada. El token necesita un claim de sujeto no vacío, y bajo el perfil genérico `XX` el mismo sujeto debe crear, aprobar y desembolsar la solicitud. Lender define sus roles y permisos en un archivo de semilla. 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 sumidero de asientos durable: siempre presente Un préstamo desembolsado registra su intención de asiento de forma durable. Lender inicializa su outbox transaccional de PostgreSQL en cada despliegue, dentro de la misma transacción de base de datos que mueve la solicitud a `disbursed`. `OUTBOX_ENABLED` no existe. El despachador transmite cada intención después, con la cadencia que define `OUTBOX_DISPATCH_INTERVAL_SEC`. Lee [Contabilidad y ejecuciones de devengo](/es/products/lender/accounting-and-accrual-runs) para saber qué recibe el ledger.

Asientos en el ledger

*** Apunta Lender a Midaz cuando quieras que los asientos aterricen en el ledger: | Variable | Propósito | | ------------------------------------------------- | ----------------------------------------------------------- | | `MIDAZ_LEDGER_BASE_URL` | La dirección del ledger. | | `MIDAZ_OAUTH_TOKEN_URL` | Dónde obtiene Lender sus credenciales de ledger. | | `MIDAZ_LEDGER_ORGANIZATION_ID`, `MIDAZ_LEDGER_ID` | El destino de asiento predeterminado en modo single-tenant. | El préstamo se origina con o sin estas. Hasta que configures un endpoint de ledger, las intenciones de asiento permanecen durables en el outbox y el asiento del ledger espera. Configura el ledger antes de esperar contabilizaciones. ## Valores predeterminados single-tenant *** `MULTI_TENANT_ENABLED` es `false` de forma predeterminada. En ese modo `DEFAULT_TENANT_ID` identifica al único tenant, y debe ser un UUID válido. ## Agregados multi-tenant *** El modo multi-tenant le da a cada tenant su propio esquema y su propio pool de clientes de ledger. Agrega cuatro requisitos: 1. Define `MULTI_TENANT_ENABLED=true` y apunta Lender al tenant manager. 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 recurre a los valores predeterminados del entorno. ## Streaming de eventos *** El streaming está apagado de forma predeterminada y la originación no lo necesita. Para publicar el catálogo de eventos de ciclo de vida, define `STREAMING_ENABLED=true`, apunta `STREAMING_BROKERS` a RedPanda y define `STREAMING_CLOUDEVENTS_SOURCE=lender`. Lender valida ese valor de fuente cuando arranca. ## Lista de verificación *** * PostgreSQL 17 y Valkey 8 accesibles. * Ambos conjuntos de migración aplicados. * Cuando la autorización por ruta está habilitada, define `PLUGIN_AUTH_ENABLED=true`, confirma que el proveedor de identidad es accesible y usa un Bearer token con un sujeto y cada permiso de la tabla de arriba. * `DEFAULT_TENANT_ID` un 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 de asiento en el ledger.