Evento organization.updated
Disparado para a organização da plataforma quando uma organização conectada muda
em um campo público relevante. Isso inclui status de ativação financeira, a
lista de tarefas da ativação (requirements), conta para saques ativa,
dados cadastrais, endereço de cobrança, branding e metadata da relação com a
plataforma.
O evento também dispara quando apenas o motivo muda: se a organização já
estava disabled e a análise adiciona ou refina uma pendência, chega um novo
organization.updated com previous_attributes.requirements — mesmo com
activation_status inalterado.
data.object carrega o estado atual completo da organização conectada (incluindo
activation_status e payout_account quando preenchidos), e
data.previous_attributes mostra o valor anterior dos campos que mudaram —
útil pra detectar transições. Quando requirements muda, o diff traz o
objeto anterior completo.
Use este evento para sincronizar o admin da plataforma sem precisar buscar a
organização novamente. Quando a conta para saques ativa muda,
data.object.payout_account traz a conta atual e
data.previous_attributes.payout_account traz a conta anterior.
O payload em
data.object é sempre o estado completo e atual. Use
data.previous_attributes apenas para saber o que mudou; a fonte do estado
final é data.object.Quando acontece
Como processar
- Registre o
iddo evento (evt_*) para processar o webhook de forma idempotente. - Use
data.object.id(org_*) para atualizar o registro local da organização conectada. - Aplique o estado completo de
data.object; não reconstrua estado final apenas pelo diff. - Use
data.previous_attributespara auditoria, notificações e regras condicionais de transição. - Libere recebimentos quando
activation_statusestiveractive; bloqueie quando estiverdisabled. - Em
not_submittedapós um envio, leiarequirements.errors, corrija os caminhos demissinge chame/submitnovamente na mesma organização. - Em
disabled, decida pelorequirements: sedisabled_reasonviernull, corrija os caminhos emmissinge inicie outra tentativa na mesma organização — outra activation session no hospedado, ou atualização +/submitpela API. Sedisabled_reasonvier preenchido, o caso é terminal: encaminhe ao suporte e não repita automaticamente. - Exiba
message/resolutionde cada erro como estão (inglês) ou traduza a partir docode; tratecodedesconhecido de forma genérica. - Atualize a conta exibida no admin usando somente os dados públicos de
payout_account, comoaccount_number_last4. - Trate ausência de uma chave em
previous_attributescomo “campo não mudou”.
Campos importantes
Status financeiros
Exemplo: envio falhou antes da análise
Quando uma submissão feita pela API falha antes de entrar na análise, o evento informa a volta paranot_submitted e mantém o motivo acionável no objeto atual:
Exemplo: cadastro aprovado
previous_attributes.requirements traz o objeto anterior completo — durante a
análise, pending_verification listava o que estava sendo verificado. Ausência
de uma chave no diff significa “campo não mudou”.
Exemplo: cadastro reprovado
disabled_reason: null indica que há caminho de correção: os caminhos em
missing dizem o que recoletar. Depois, inicie outra tentativa na mesma
organização pelo canal da integração — outra activation session no hospedado,
ou atualização + /submit pela API.
Exemplo: motivo mudou, status não
Quando a análise adiciona ou refina uma pendência de uma organização que já estavadisabled, o diff carrega apenas requirements:

