> ## 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. # Pix Lerian events > The CloudEvents Pix Lerian publishes for SPI, DICT, COB, and Pix Automático business facts, how they are delivered, and how to discover each payload's schema. Pix Lerian emits business facts as CloudEvents 1.0 in binary content mode. Four components publish onto the same topic — SPI, DICT Hub, COB Hub, and the Pix Automático payer API — because they are modules of one application and share one CloudEvents source, `plugin-br-pix-lerian`. Streaming Hub delivers these events to your institution's systems. ## How delivery works *** * **At least once.** The use case writes the business state and the event envelope in the same transaction, into an outbox; the outbox relay is the only broker publisher. An event can arrive more than once, but it is never lost once the state change is committed. * **Two consumption paths.** [Streaming Hub](https://docs.lerian.studio/en/platform/streaming-hub/what-is-streaming-hub.md) delivers each matching event to a sink of yours — an HTTPS webhook with an HMAC signature, SQS, RabbitMQ, or EventBridge — or your consumer subscribes to the `lerian.streaming.plugin-br-pix-lerian` topic with any Kafka client. * **Deduplicate.** On the webhook, by the `X-Lerian-Event-Id` header; on Kafka, by the `(ce-source, ce-id)` pair. * **Do not rely on arrival order.** The record key is `:`, which gives partition affinity per tenant and aggregate, not strict ordering. Order by the lifecycle and by the timestamps inside each event. * **Dispatch on `ce-type`.** The type is `studio.lerian.plugin-br-pix-lerian.` and the record value is the payload alone (`data`), with no envelope. Ignore types you do not handle: new events appear without notice, on the same topic. * Monetary values arrive as decimal strings; interpret them as decimals, never as binary floating point. Timestamps are in UTC. On the webhook path, verify the HMAC signature over the raw request body before any parsing and answer `2xx` only after the verification passes and the event is persisted on your side. The verification walkthrough, secret rotation, and the `X-Lerian-*` headers are in [Consuming events](https://docs.lerian.studio/en/platform/streaming-hub/consuming-events.md); creating the sink is covered in [Managing subscriptions](https://docs.lerian.studio/en/platform/streaming-hub/managing-subscriptions.md). ## Schema discovery *** Each producing component serves two HTTP endpoints under its own route prefix: ```http theme={null} GET {origin}{prefix}/v1/streaming/manifest GET|HEAD {origin}{prefix}/v1/streaming/schemas/{eventKey}/{schemaVersion} ``` | Component | Prefix | | - | - | | SPI | `/spi` | | DICT Hub | `/dict-hub` | | COB Hub | `/cob-hub` | | Pix Automático payer API | `/pixauto` | The manifest lists the events the component publishes and points at the JSON Schema document for each `(eventKey, schemaVersion)` pair. Use it as the deploy-time contract instead of guessing topics and formats. Both endpoints share a single authorization grant, `streaming-manifest`/`get`, scoped to the component's application name (`plugin-br-pix-lerian-spi`, `-dict`, `-cob`, `-pixauto`); send the token as `Authorization: Bearer `. Installations running with authorization disabled serve both endpoints unauthenticated. > [!NOTE] > > Read `ce-schemaversion` on each record and cache the schema document on the `(eventKey, schemaVersion)` pair. Producers write records at each event's current version only; a superseded version is never edited and its document stays served for consumers still pinned to it. ## Catalog *** Every `ce-type` uses `studio.lerian.plugin-br-pix-lerian.`. The authoritative machine-readable list is each component's manifest; the tables below are the same set in prose. ### SPI | Event key | What it announces | | - | - | | `outbound_transfer.completed` | A Pix payment the organization sent settled. | | `outbound_transfer.rejected` | A Pix payment the organization sent was refused; the ledger movement was compensated. | | `inbound_transfer.completed` | A Pix payment the organization received settled. | | `refund.completed` | A Pix refund settled. | | `refund.failed` | A Pix refund could not be settled. | | `scheduled_payment.settled` | A scheduled Pix order settled: the rail confirmed the payment and the ledger hold was committed. | | `scheduled_payment.failed` | A scheduled Pix order failed for good: no further attempt is authorized on a later day. | | `scheduled_payment.cancelled` | A scheduled Pix order was cancelled — a fact about the payee: their key changed hands or no longer resolves. | | `scheduled_payment.funds_missing_first_window` | The first sending window closed with the order unpaid for lack of balance. The order is not terminal: a further attempt is obliged between 18:00 and 21:00. | | `scheduled_payment.funds_missing_final` | At the day close (21:00), the day's attempts were exhausted and the order will not be attempted again. | | `scheduled_payment.limit_exceeded` | A sending window closed with the order unpaid because the payer's own limit would be exceeded; only notification is required, with no further attempt. | ### DICT Hub | Event key | What it announces | | - | - | | `claim.completed` | A key claim reached COMPLETED: the key moved to the claiming participant. | | `claim.cancelled` | A claim reached CANCELLED: the key stays with the donor. | | `claim.confirmed` | The donor participant agreed to release the key. | | `claim.waiting_resolution` | The directory acknowledged the claim; the donor's resolution window is running. | | `funds_recovery.updated` | Any persisted change to a MED funds recovery. | | `infraction_report.updated` | Any persisted change to a MED infraction report. | | `refund_request.updated` | Any persisted change to a MED refund request. | | `reconciliation_job.updated` | A status transition of a key-directory reconciliation job. | ### COB Hub | Event key | What it announces | | - | - | | `collection.paid` | A Pix collection settled. Branch on the `type` field: `IMMEDIATE` (cob) or `DUE_DATE` (cobv). | ### Pix Automático | Event key | What it announces | | - | - | | `pix_auto_request.received` | An authorization request was raised and awaits the payer's decision. | | `pix_auto_request.rejected` | The payer refused an authorization request. | | `pix_auto_request.expired` | The request's decision deadline elapsed unanswered. | | `pix_auto_request.cancelled` | The counterparty withdrew the request before the payer answered. | | `pix_auto_authorization.granted` | The payer accepted the request; the authorization exists. | | `pix_auto_authorization.parameters_changed` | The payer reconfigured an active authorization. | | `pix_auto_authorization.revoked` | An authorization was revoked, with the size of the resulting cascade. | | `pix_auto_authorization.awaiting_conclusion` | The concession was filed; the receiving institution's answer is pending. | | `pix_auto_authorization.concluded` | The conclusive answer arrived. | | `pix_auto_authorization.conclusion_timed_out` | The one-hour bound elapsed with no conclusive answer. | | `pix_auto_consent.revoked` | An Open Finance recurring consent was revoked at the payer PSP, with the size of the resulting cascade. | | `pix_auto_recurrence.cancelled` | The recurrence itself was cancelled at the counterparty, whether or not an authorization existed over it. | | `pix_auto_scheduled_payment.cancelled` | One scheduled charge stopped while its authorization stays active. | | `pix_auto_scheduled_payment.cancellation_confirmed` | The receiving participant accepted (camt.029 ACCR) the camt.055 this end sent; the charge was already cancelled. | | `pix_auto_scheduled_payment.cancellation_refused` | The receiving participant refused (camt.029 RJCR) the camt.055 this end sent; the charge stays cancelled. | | `pix_auto_scheduled_payment.resend_refused` | A same-day resend (pain.013 RIFL) arrived at or after 21:00 Brasília time and was refused. | | `pix_auto_scheduled_payment.settlement_deferred` | The morning window closed without settlement; a further attempt runs the same day between 18:00 and 21:00. | | `pix_auto_scheduled_payment.settlement_failed` | The charge could not be settled that day and its recurrence permits no post-due retry. | | `pix_auto_scheduled_payment.settlement_retry_permitted` | The charge did not settle that day and its recurrence permits post-due retries. | | `pix_auto_scheduled_payment.settlement_outcome_pending` | This end cannot yet call the charge's settlement either way. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.