> ## 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 Direct via JD events

> CloudEvents emitted by the Pix Direct via JD integration for transaction, DICT key, and Pix Automático lifecycles.

The Pix Direct via JD integration emits 21 JSON business facts as CloudEvents 1.0 in binary content mode over Kafka. Streaming is optional. When enabled, the integration writes the business state and event envelope to the PostgreSQL outbox in the same transaction; the outbox relay is the only broker publisher.

## Transport contract

| Field            | Value                                          |
| ---------------- | ---------------------------------------------- |
| `ce-source`      | `plugin-br-pix-jd`                             |
| Topic            | `lerian.streaming.plugin-br-pix-jd`            |
| Schema version   | `1.0.0` for every event                        |
| Content type     | `application/json`                             |
| Delivery         | At least once through the transactional outbox |
| Command topic    | None                                           |
| Runtime manifest | Not exposed                                    |

Set `STREAMING_ENABLED=true` and `OUTBOX_ENABLED=true` together. If you set `STREAMING_CLOUDEVENTS_SOURCE`, its value must be exactly `plugin-br-pix-jd`. When streaming is disabled, the integration does not write lifecycle events to the streaming outbox.

<Warning>
  This integration does not expose a streaming manifest endpoint yet. Its bootstrap catalog contains only the structural `transaction.created` definition, while the production emit paths below publish all 21 facts. Use this page—not the incomplete runtime catalog—as the current event inventory.
</Warning>

Deduplicate on `(ce-source, ce-id)` and keep consumers idempotent. The integration provisions no command topic.

## Event catalog

Every `ce-type` uses `studio.lerian.plugin-br-pix-jd.<event-key>`.

### Transactions

| Event key              | Fires when                                                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `transaction.created`  | An external cash-out is persisted as pending, its pending Midaz posting exists, and the JDPI submission succeeds.   |
| `transaction.executed` | An internal transfer completes synchronously, a cash-in is applied, or reconciliation settles an external cash-out. |
| `transaction.refunded` | A refund transaction is persisted and linked to the original transaction.                                           |
| `transaction.failed`   | Reconciliation moves a pending external cash-out to its terminal error state and cancels the pending posting.       |

### DICT keys and claims

| Event key                  | Fires when                                                                                 |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| `key.registered`           | A key is registered in DICT and persisted as active.                                       |
| `key.validation-requested` | The integration stores and dispatches an ownership-validation challenge.                   |
| `key.confirmed`            | The submitted challenge is verified and the key leaves the waiting-for-confirmation state. |
| `key.deleted`              | A key is deleted in DICT and soft-deleted locally.                                         |
| `key.claimed`              | A claim is opened in DICT and its identifier is persisted.                                 |
| `key.claim-confirmed`      | The donor confirms the claim.                                                              |
| `key.claim-concluded`      | The claimer concludes the claim.                                                           |
| `key.claim-cancelled`      | The claim is cancelled.                                                                    |

### Pix Automático authorizations

| Event key                 | Fires when                                                                                |
| ------------------------- | ----------------------------------------------------------------------------------------- |
| `authorization.requested` | The receiving PSP requests an authorization and the integration persists it as requested. |
| `authorization.accepted`  | The payer accepts the authorization.                                                      |
| `authorization.rejected`  | The authorization transitions to rejected.                                                |
| `authorization.activated` | The authorization is confirmed successfully and transitions to active.                    |
| `authorization.cancelled` | The authorization is cancelled and soft-deleted.                                          |

### Pix Automático schedules

| Event key            | Fires when                                                                                  |
| -------------------- | ------------------------------------------------------------------------------------------- |
| `schedule.requested` | The receiving PSP requests a payment schedule and the integration persists it as requested. |
| `schedule.accepted`  | The schedule transitions to accepted.                                                       |
| `schedule.rejected`  | The schedule transitions to rejected.                                                       |
| `schedule.cancelled` | The schedule is cancelled and soft-deleted.                                                 |

## Payload contracts

All timestamps are UTC RFC 3339 strings. Transaction and Pix Automático monetary values are integer centavos, not decimal strings or floating-point numbers. Fields marked with `?` can be omitted.

<Warning>
  The wire contract encodes `amount`, `value`, and `payerMaxValue` as JSON `int64` number tokens. JavaScript consumers that accept the full `int64` range must use lossless, BigInt-aware JSON parsing or reject values above `Number.MAX_SAFE_INTEGER`; standard `JSON.parse` can round larger integers.
</Warning>

```typescript theme={null}
interface TransactionEventData {
  id: string
  jdpiRequestId?: string
  indirectId?: string
  endToEndId?: string
  status: string
  flow: number
  type: number
  amount: number // int64 centavos
  accountId: string
  isRefund: boolean
  isInternal: boolean
  refundType?: number
  refundAccountId?: string
  refundEndToEndId?: string
  refundCode?: string
  createdAt: string
  updatedAt: string
}

interface KeyEventData {
  id: string
  key: string
  accountId: string
  status: number
  keyType: number
  claimId?: string
  claimType?: number
  createdAt: string
  updatedAt: string
}

interface AuthorizationEventData {
  id: string
  idRecorrencia: string
  idReqJdPi?: string
  idCancelamento?: string
  tenantId?: string
  status: number
  frequency: number
  value?: number // int64 centavos
  payerMaxValue?: number // int64 centavos
  recipientIspb?: string
  recipientCnpj?: string
  payerCpfCnpj?: string
  contractNumber?: string
  createdAt: string
  updatedAt: string
}

interface ScheduleEventData {
  id: string
  endToEndId: string
  idRecorrencia: string
  idConciliacaoRecebedor?: string
  idCancelamento?: string
  tenantId?: string
  status: number
  finalidadeAgendamento: number
  dtVencimento?: string
  value?: number // int64 centavos
  recipientIspb?: string
  recipientCnpj?: string
  payerCpfCnpj?: string
  createdAt: string
  updatedAt: string
}
```