Único tipo de mensagem enviado pela IORQ. O corpo do POST para a URL registrada é o objeto payload acrescido de iorq_fund_id (UUID do fundo do evento, útil para roteamento em integrações multi-fundo) e event_timestamp (instante em que a IORQ gerou o evento, ISO-8601 UTC) no topo; o que aconteceu é discriminado por data.status (ex.: approved, rejected, settled_installment, received_prepayment, due_date_changed, approved_renegotiation, rejected_renegotiation, invalid_renegotiation, acquisition_completed, settlement_completed, repurchase_completed, renegotiation_completed, invalid, invalid_settlement, invalid_prepayment, invalid_repurchase). Cada entrega é assinada no formato Standard Webhooks: headers webhook-id (o evento, o mesmo em todas as tentativas), webhook-timestamp e webhook-signature (v1,<base64> sobre "{webhook-id}.{webhook-timestamp}.{corpo}"), além dos headers custom registrados no webhook. A assinatura legada X-IORQ-Signature (t=<ts>,v1=<hex> sobre "{ts}.{corpo}") e X-IORQ-Timestamp seguem saindo, mantidas até data a ser anunciada. Entrega at-least-once: deduplique pelo conteúdo de data.
Recebido. Só um 2xx marca como entregue; qualquer outra resposta, e o timeout de 10 s, dispara a reentrega (pela política da IORQ, até 11 tentativas em cerca de 70 h; o max_attempts do webhook pode mudar o total). A IORQ não segue redirect: responda na própria URL registrada, porque um 3xx conta como falha.