Skip to main content

​
Why this matters

Transaction lifecycle events let downstream systems react without coupling to the transaction API. Use them for notifications, reconciliation, analytics, and compliance workflows. For the complete catalog and consumer contract, see Receiving Midaz events.

​
Enable transaction lifecycle events

Midaz publishes lifecycle CloudEvents through the Kafka-compatible lib-streaming surface. Publication is disabled by default. Configure the ledger application with a broker list and its roster source:
STREAMING_CLOUDEVENTS_SOURCE is required when streaming is enabled. The ledger, CRM, and Fees binary uses ledger; the transaction facts publish to lerian.streaming.ledger. If streaming is enabled without STREAMING_BROKERS, Midaz refuses to start. When streaming is disabled, Midaz uses a no-op emitter.

​
Lifecycle events

Midaz emits these public facts for eligible persisted transaction state changes: Midaz does not emit a lifecycle fact for a newly created PENDING transaction, a NOTED transaction, or a no-op state change. A pending transaction emits only when a later status update commits or cancels it.

​
Consume events

Subscribe to lerian.streaming.ledger and select the facts you need using the CloudEvents headers. Do not infer event type from the Kafka topic: Midaz uses one application topic for ledger, CRM, and Fees facts. Use the producer manifest as the deployment-time contract:
The manifest remains available even when publication is disabled. The Midaz event reference lists the event payloads.
Event publication is best effort and does not make the broker write transactional with the ledger mutation. Consumers must be idempotent and deduplicate on (ce-source, ce-id).