> ## 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. # Eventos de Lender > Suscríbete a la jornada de crédito: el source fijo de CloudEvents, las formas de topic y de ce-type, los 21 eventos de la jornada documentada, la garantía de durabilidad del outbox y qué lleva un payload. Lender publica un evento de negocio cada vez que un producto, una solicitud, una cuenta de préstamo o un registro regulatorio brasileño cambia de estado. Suscríbete a esos eventos y tu servicio reacciona a cada cambio a medida que ocurre, sin loop de polling. Cada evento está respaldado por el outbox y tiene alcance por tenant. Esta página cubre el lado del consumidor: qué llega al wire, qué eventos existen y cómo hacer que un handler sea seguro. ## Activa la publicación *** Publicar eventos es una decisión de despliegue. La originación funciona sin ella. | Ajuste | Valor | | ------------------------------ | --------------------------------------------------------------------------------------- | | `STREAMING_ENABLED` | `true` | | `STREAMING_BROKERS` | Las direcciones de RedPanda. | | `STREAMING_CLOUDEVENTS_SOURCE` | `lender`. Lender exige exactamente este valor y lo valida al arrancar. | | `OUTBOX_ENABLED` | `true`. Cada evento está respaldado por el outbox, así que publicar necesita el outbox. | Lender se niega a arrancar cuando la publicación está activa y algo de esto está mal, así que un despliegue mal configurado falla al arrancar en lugar de perder eventos en silencio. ## El contrato del wire *** El source de CloudEvents es el literal fijo `lender`, y el source también sirve de namespace para cada topic. Así, un suscriptor lee: | Elemento del wire | Valor | | ------------------- | ---------------------------------------------------------------- | | Topic de Kafka | `lender..` | | Header `ce-source` | `lender` | | Header `ce-type` | `studio.lerian..` | | Header `ce-subject` | El identificador del registro que cambió. | | Clave de partición | El tenant, para que los eventos de un tenant conserven su orden. | Para un desembolso eso resuelve a: ``` topic lender.loan_application.disbursed ce-type studio.lerian.loan_application.disbursed ``` Los mensajes viajan en modo binario de CloudEvents, versión 1.0. Los atributos de contexto viajan como headers del mensaje: `ce-specversion`, `ce-id`, `ce-source`, `ce-type`, `ce-time`, `ce-schemaversion`, `ce-resourcetype` y `ce-eventtype` en cada mensaje, más `ce-subject`, `ce-datacontenttype` y `ce-tenantid` cuando Lender tiene un valor para ellos. `ce-schemaversion` es `1.0.0` para cada evento del catálogo. El topic no lleva sufijo de versión en esta versión de esquema, así que suscríbete al nombre de topic simple. **Suscríbete por topic.** El topic es la dirección, y se compone del resource type y del event type — no de un nombre interno de catálogo. Lee la columna de topic en las tablas siguientes en lugar de derivar uno desde la descripción de un evento. ## Los eventos *** Esta página cubre los **21 eventos de la jornada de crédito documentada**. Se agrupan por la parte de la jornada que reportan. El manifiesto de streaming declara todo el catálogo de tu despliegue, que puede llevar más definiciones que las que lista esta página. ### Productos | Topic | Se emite cuando | | -------------------------------------- | ------------------------------------------------------------------- | | `lender.loan_product.created` | Se crea un producto como definición en borrador. | | `lender.loan_product.activated` | Un producto pasa a activo y fija su versión actual. | | `lender.loan_product_version.created` | Se agrega un snapshot de versión como términos inmutables. | | `lender.accounting_profile.configured` | Un perfil y sus reglas de posting quedan vinculados a una versión. | | `lender.loan_charge.applied` | Un cargo de versión de producto se aplica a una cuenta de préstamo. | ### Originación | Topic | Se emite cuando | | ----------------------------------- | ----------------------------------------------------------------------------- | | `lender.loan_application.submitted` | Se acepta una solicitud y queda esperando aprobación. | | `lender.loan_application.approved` | Se aprueba una solicitud, con los hechos de la decisión. | | `lender.loan_application.rejected` | Se rechaza una solicitud, con los hechos de la decisión. | | `lender.loan_application.withdrawn` | Se retira una solicitud pendiente. | | `lender.loan_application.disbursed` | Se desembolsa una solicitud aprobada y una cuenta de préstamo entra en vigor. | ### Servicing | Topic | Se emite cuando | | ----------------------------------------- | --------------------------------------------------------------- | | `lender.repayment.recorded` | Se registra un pago, con su asignación de efectivo. | | `lender.repayment_reversal.recorded` | Se registra una reversión como transacción compensatoria. | | `lender.loan_schedule.prepayment_applied` | Un prepago produce una versión sucesora del cronograma. | | `lender.loan_schedule.rescheduled` | Una reprogramación produce una versión sucesora del cronograma. | ### Paquete Brasil | Topic | Se emite cuando | | -------------------------------------------- | ------------------------------------------------------------------------------- | | `lender.loan_account.pdd_stage_transitioned` | Se registra una transición o cura de etapa PDD, con su elegibilidad de devengo. | | `lender.prepayment_quote.created` | Se crea una cotización de prepago inmutable. | | `lender.prepayment_settlement.recorded` | Una cotización aceptada se liquida, con el desglose final. | ### Consignado privado | Topic | Se emite cuando | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | `lender.consignado_exclusao.requested` | Lender pide al rail de nómina cancelar una averbação. | | `lender.consignado_redirecionamento.requested` | Lender pide al rail de nómina redirigir la cobranza a otro vínculo laboral. | | `lender.payroll_deduction.refund_required` | Llegó efectivo confirmado de nómina después del pago total y el prestatario tiene un reembolso a favor. | | `lender.guarantee_recovery_cash.allocated` | Se asigna un ingreso confirmado de recuperación de garantía. | La jornada de consignado también **consume** hechos del gateway de descuento en nómina, en los topics de ese producto. Consulta [Consignado privado](/es/lender/consignado-privado). ## Durabilidad y entrega *** Cada evento del catálogo lleva la misma política de entrega. Nada publica directo al broker. Lender escribe el evento en un outbox transaccional en la **misma transacción de base de datos** que el cambio de estado, y un dispatcher lo transmite después. El evento por lo tanto sobrevive a una caída, y sobrevive a una caída del broker mientras el dispatcher reintenta. El presupuesto de reintentos es acotado. El dispatcher da a un evento los intentos de `OUTBOX_MAX_DISPATCH_ATTEMPTS`, y el valor por defecto es `10`. Espera `OUTBOX_RETRY_WINDOW_SEC` segundos entre intentos, y el valor por defecto es `300`. Pasado ese presupuesto el dispatcher deja de reintentar el evento. Sube el presupuesto cuando esperes caídas más largas que la ventana por defecto. Los eventos viajan por el mismo outbox que el relay del ledger, así que el cambio de estado local y el evento se confirman juntos en una sola transacción de base de datos. La intención de posting se les suma cuando el cambio produce una. La contabilización en el ledger llega después. Lee [Contabilidad y ejecuciones de devengo](/es/lender/accounting-and-accrual-runs). **La entrega es al menos una vez.** Un evento puede llegar más de una vez, y una reentrega lleva los mismos hechos. Haz cada handler idempotente sobre el identificador del registro en el payload, que también viaja en `ce-subject`. ## Qué lleva un payload *** El body es JSON y lleva los hechos del cambio, no un diff. Un body de `loan_application.disbursed`: ```json theme={null} { "loanApplicationId": "018f2a1c-7d40-7b31-9d40-2f1e8c5a4b77", "loanProductVersionId": "8f2c1a9e-4b30-4c02-9a1b-2d5e6f7a1c33", "borrowerId": "borrower-0001", "assignedOfficerId": "officer-0007", "status": "disbursed", "loanAccountId": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "disbursementEventId": "019826f4-6a9c-7b31-8a02-11c3d4e5f678", "grossRequestedAmount": "48000.00", "netDeliveredAmount": "48000.00", "disbursedAt": "2026-08-01T13:00:00Z", "previewJurisdictionCode": "XX", "updatedAt": "2026-08-01T13:00:00Z" } ``` **El dinero y las tasas viajan como strings decimales**, nunca como números JSON, igual que sobre REST. Parséalos con un tipo decimal. Las marcas de tiempo son RFC 3339 en UTC. Cada evento lleva los hechos que guarda su propio registro, así que lee la forma del evento al que te suscribes. Un evento brasileño agrega lo que su regulación necesita: una transición de PDD lleva la etapa y la elegibilidad de devengo, y una cotización de prepago lleva el descuento y la reconciliación de IOF. ## Verifica el contrato al arrancar *** `GET /api/v1/streaming/manifest` devuelve el manifiesto del catálogo: cada definición de evento con su resource type, event type, versión de esquema y política de entrega. Pide un token bearer con `streaming_manifest` `read`. Reporta todo el catálogo declarado del despliegue, no la vista de un tenant. Léelo cuando arranque tu consumidor. Compara cada evento al que te suscribes con el manifiesto: el resource type, el event type y la versión de esquema. Eso detecta un desajuste de nombre o de versión en el arranque en lugar de en tiempo de ejecución. ## Próximos pasos *** La ruta base, autenticación, idempotencia y las operaciones por trabajo. Las partes del servicio, la ruta del outbox y el trabajo por tiempo. Dónde se ubica Lender junto a Midaz, Access Manager y el backbone de streaming. La jornada de descuento en nómina y los hechos que consume.