Skip to main content

Visão geral

Os eventos webhook de segurança notificam seu SIEM ou ferramentas de monitoramento quando ações de IAM ocorrem no Gu1: ciclo de vida de membros, mudanças de perfis, login/logout, logins falhos, ações admin de senha e certas configurações de segurança. Configure-os como qualquer outro webhook em Configurações → Webhooks e inscreva-se apenas nos eventos security.* necessários.

Formato do payload (todos os eventos de segurança)

Cada webhook de segurança usa o envelope padrão mais um payload interno normalizado:

Eventos disponíveis

Membros (security.member.*)

context.teamType (ex.: production, sandbox) e context.teamRole aplicam-se a eventos de equipe. Para acesso a ambientes, context.environment é "production" ou "sandbox", com context.environmentOrganizationId e context.environmentOrganizationName. Em security.member.environment_changed, use context.fromAccess / context.toAccess ("both" | "production" | "sandbox" | "none") e changes.environmentAccess. Webhooks de canal disparam no contexto da org pai; context.channelOrganizationId identifica o canal.

Ciclo de convite (security.member.invitedsecurity.member.created)

Se você assinar os dois eventos, espere duas entregas separadas nesta ordem: O que o integrador deve esperar:
  • Não espere security.member.created no mesmo instante de security.member.invited. O convidado precisa aceitar primeiro; a entrega costuma ser segundos ou minutos depois.
  • Em security.member.created, actor e affectedUser em geral referem-se ao novo membro (mesmo UUID de usuário Gu1). affectedUser.email é o e-mail convidado.
  • payload.description normalmente é "Member accepted organization invitation". Em casos raros em que a configuração secundária (acesso ao sandbox pareado, papéis granulares ou atribuição a equipe) não pôde ser aplicada por completo no mesmo passo, a descrição pode ser "Member accepted organization invitation (environment sync incomplete)". O membro ainda tem acesso no contexto da organização do convite — trate o webhook como criação bem-sucedida do membro para SIEM e governança de acessos.
  • Se receber invited mas nunca created depois que o usuário confirmar que entrou na Gu1, verifique se seu endpoint respondeu HTTP 2xx em eventos próximos ao momento da aceitação e contate o suporte Gu1 com timestamp aproximado e organizationId.
  • Use payload.context.invitationId para correlacionar invited e created do mesmo convite (mesmo UUID nos dois eventos quando a aceitação for bem-sucedida).
Campos de context em convites (em security.member.invited e security.member.created quando aplicável): Exemplo de payload security.member.invited:
Exemplo de payload security.member.created:
Eventos de acompanhamento relacionados (mesmo membro, webhooks separados quando aplicável): security.member.environment_granted, security.member.team_added, security.member.channel_granted, security.role.assigned.

Perfis e RBAC (security.role.*, security.rbac.*)

Autenticação (security.auth.*)

Configurações de segurança

Limitações

Não são cobertos hoje pelos webhooks de segurança Gu1:
  • Alteração de senha self-service do usuário no Clerk (somente IdP)
  • Mudanças MFA / SSO no Clerk
  • Autenticação API key M2M (distinta do login de usuário)
  • Revogações de sessão feitas apenas no dashboard Clerk
Reset/geração de senha por admin são cobertos via security.member.password_*.

Relacionado