> ## 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 Pix Lerian > Los CloudEvents que Pix Lerian publica para los hechos de negocio de SPI, DICT, COB y Pix Automático, cómo se entregan y cómo descubrir el schema de cada payload. Pix Lerian emite hechos de negocio como CloudEvents 1.0 en modo binario de contenido. Cuatro componentes publican en el mismo tópico — SPI, DICT Hub, COB Hub y la API del pagador de Pix Automático — porque son módulos de una única aplicación y comparten un único origen CloudEvents, `plugin-br-pix-lerian`. Streaming Hub entrega estos eventos a los sistemas de tu institución. ## Cómo funciona la entrega *** * **Al menos una vez.** El caso de uso graba el estado de negocio y el sobre del evento en la misma transacción, en un outbox; el relay del outbox es el único publisher del broker. Un evento puede llegar más de una vez, pero nunca se pierde una vez confirmado el cambio de estado. * **Dos caminos de consumo.** [Streaming Hub](https://docs.lerian.studio/es/platform/streaming-hub/what-is-streaming-hub.md) entrega cada evento coincidente a un sink tuyo — webhook HTTPS con firma HMAC, SQS, RabbitMQ o EventBridge — o tu consumidor se suscribe al tópico `lerian.streaming.plugin-br-pix-lerian` con cualquier cliente Kafka. * **Elimina duplicados.** En el webhook, por el header `X-Lerian-Event-Id`; en Kafka, por el par `(ce-source, ce-id)`. * **No dependas del orden de llegada.** La clave del registro es `:`, lo que da afinidad de partición por tenant y agregado, no orden estricto. Ordena por el ciclo de vida y por los timestamps dentro de cada evento. * **Despacha por `ce-type`.** El tipo es `studio.lerian.plugin-br-pix-lerian.` y el valor del registro es solo el payload (`data`), sin sobre. Ignora los tipos que no manejas: eventos nuevos aparecen sin aviso, en el mismo tópico. * Los valores monetarios llegan como string decimal; interprétalos como decimales, nunca como punto flotante binario. Los timestamps están en UTC. En el camino por webhook, verifica la firma HMAC sobre los bytes crudos del cuerpo antes de cualquier parseo y responde `2xx` solo después de que la verificación pase y el evento esté persistido de tu lado. El paso a paso de verificación, la rotación del secreto y los headers `X-Lerian-*` están en [Consumir eventos](https://docs.lerian.studio/es/platform/streaming-hub/consuming-events.md); la creación del sink está en [Gestionar subscriptions](https://docs.lerian.studio/es/platform/streaming-hub/managing-subscriptions.md). ## Descubrimiento de schema *** Cada componente productor sirve dos endpoints HTTP bajo su propio prefijo de ruta: ```http theme={null} GET {origin}{prefix}/v1/streaming/manifest GET|HEAD {origin}{prefix}/v1/streaming/schemas/{eventKey}/{schemaVersion} ``` | Componente | Prefijo | | - | - | | SPI | `/spi` | | DICT Hub | `/dict-hub` | | COB Hub | `/cob-hub` | | API del pagador de Pix Automático | `/pixauto` | El manifiesto lista los eventos que el componente publica y apunta al documento JSON Schema de cada par `(eventKey, schemaVersion)`. Úsalo como contrato en tiempo de deploy, en lugar de adivinar tópicos y formatos. Los dos endpoints comparten un único grant de autorización, `streaming-manifest`/`get`, acotado al application name del componente (`plugin-br-pix-lerian-spi`, `-dict`, `-cob`, `-pixauto`); envía el token como `Authorization: Bearer `. Las instalaciones con la autorización deshabilitada sirven los dos endpoints sin autenticación. > [!NOTE] > > Lee `ce-schemaversion` en cada registro y guarda en caché el documento de schema por el par `(eventKey, schemaVersion)`. Los productores escriben registros solo en la versión vigente de cada evento; una versión reemplazada nunca se edita y su documento sigue servido para los consumidores aún fijados a ella. ## Catálogo *** Todo `ce-type` usa `studio.lerian.plugin-br-pix-lerian.`. La lista autoritativa legible por máquina es el manifiesto de cada componente; las tablas de abajo son el mismo conjunto en prosa. ### SPI | Clave del evento | Qué anuncia | | - | - | | `outbound_transfer.completed` | Un pago Pix enviado por la organización fue liquidado. | | `outbound_transfer.rejected` | Un pago Pix enviado por la organización fue rechazado; el movimiento en el ledger fue compensado. | | `inbound_transfer.completed` | Un pago Pix recibido por la organización fue liquidado. | | `refund.completed` | Una devolución Pix fue liquidada. | | `refund.failed` | Una devolución Pix no pudo liquidarse. | | `scheduled_payment.settled` | Un Pix programado fue liquidado: el riel confirmó el pago y la retención en el ledger se hizo efectiva. | | `scheduled_payment.failed` | Un Pix programado falló definitivamente: no se autoriza ningún intento en un día posterior. | | `scheduled_payment.cancelled` | Un Pix programado fue cancelado — un hecho sobre el receptor: su clave cambió de titular o dejó de resolver. | | `scheduled_payment.funds_missing_first_window` | La primera ventana de envío cerró con la orden sin pagar por falta de saldo. La orden no es terminal: un nuevo intento es obligatorio entre las 18:00 y las 21:00. | | `scheduled_payment.funds_missing_final` | Al cierre del día (21:00), los intentos del día se agotaron y la orden no se intentará de nuevo. | | `scheduled_payment.limit_exceeded` | Una ventana de envío cerró con la orden sin pagar porque se excedería el límite del propio pagador; solo se exige la notificación, sin nuevo intento. | ### DICT Hub | Clave del evento | Qué anuncia | | - | - | | `claim.completed` | Una reivindicación de clave llegó a COMPLETED: la clave pasó al participante reivindicador. | | `claim.cancelled` | Una reivindicación llegó a CANCELLED: la clave permanece con el donante. | | `claim.confirmed` | El participante donante aceptó liberar la clave. | | `claim.waiting_resolution` | El directorio reconoció la reivindicación; la ventana de resolución del donante está corriendo. | | `funds_recovery.updated` | Cualquier cambio persistido en una recuperación de fondos del MED. | | `infraction_report.updated` | Cualquier cambio persistido en un reporte de infracción del MED. | | `refund_request.updated` | Cualquier cambio persistido en una solicitud de devolución del MED. | | `reconciliation_job.updated` | Una transición de estado de un job de conciliación con el directorio de claves. | ### COB Hub | Clave del evento | Qué anuncia | | - | - | | `collection.paid` | Un cobro Pix fue liquidado. Ramifica por el campo `type`: `IMMEDIATE` (cob) o `DUE_DATE` (cobv). | ### Pix Automático | Clave del evento | Qué anuncia | | - | - | | `pix_auto_request.received` | Una solicitud de autorización fue creada y espera la decisión del pagador. | | `pix_auto_request.rejected` | El pagador rechazó una solicitud de autorización. | | `pix_auto_request.expired` | El plazo de decisión de la solicitud expiró sin respuesta. | | `pix_auto_request.cancelled` | La contraparte retiró la solicitud antes de que el pagador respondiera. | | `pix_auto_authorization.granted` | El pagador aceptó la solicitud; la autorización existe. | | `pix_auto_authorization.parameters_changed` | El pagador reconfiguró una autorización activa. | | `pix_auto_authorization.revoked` | Una autorización fue revocada, con el tamaño de la cascada resultante. | | `pix_auto_authorization.awaiting_conclusion` | La concesión fue registrada; la respuesta de la institución receptora está pendiente. | | `pix_auto_authorization.concluded` | Llegó la respuesta concluyente. | | `pix_auto_authorization.conclusion_timed_out` | El límite de una hora expiró sin respuesta concluyente. | | `pix_auto_consent.revoked` | Un consentimiento recurrente de Open Finance fue revocado en el PSP del pagador, con el tamaño de la cascada resultante. | | `pix_auto_recurrence.cancelled` | La propia recurrencia fue cancelada en la contraparte, exista o no una autorización sobre ella. | | `pix_auto_scheduled_payment.cancelled` | Un cargo programado se detuvo mientras su autorización sigue activa. | | `pix_auto_scheduled_payment.cancellation_confirmed` | El participante receptor aceptó (camt.029 ACCR) el camt.055 enviado por este extremo; el cargo ya estaba cancelado. | | `pix_auto_scheduled_payment.cancellation_refused` | El participante receptor rechazó (camt.029 RJCR) el camt.055 enviado; el cargo permanece cancelado. | | `pix_auto_scheduled_payment.resend_refused` | Un reenvío el mismo día (pain.013 RIFL) llegó a las 21:00 de Brasilia o después y fue rechazado. | | `pix_auto_scheduled_payment.settlement_deferred` | La ventana de la mañana cerró sin liquidación; un nuevo intento corre el mismo día entre las 18:00 y las 21:00. | | `pix_auto_scheduled_payment.settlement_failed` | El cargo no pudo liquidarse ese día y su recurrencia no permite reintentos después del vencimiento. | | `pix_auto_scheduled_payment.settlement_retry_permitted` | El cargo no se liquidó ese día y su recurrencia permite reintentos después del vencimiento. | | `pix_auto_scheduled_payment.settlement_outcome_pending` | Este extremo aún no puede afirmar el desenlace de la liquidación del cargo. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.