Gatilhos de eventos de autenticação
Conecte o Supabase para disparar e-mails com a cara da sua marca quando alguém se cadastra, confirma o e-mail, troca a senha ou é banido. Um script de configuração adiciona um trigger à sua tabela auth.users, e o Brew transforma cada mudança em um dos 12 gatilhos de automação.
O Supabase Auth continua responsável pelo login, pelos links de confirmação, pelos links mágicos e pelas redefinições de senha. O Brew cria e envia os e-mails que vêm depois dessas mudanças.
O evento auth.user.signed_in é disparado quando last_sign_in_at muda. As renovações de token do Supabase também mudam essa coluna, então o evento pode ser disparado várias vezes enquanto o usuário continua logado. Ele não indica que alguém voltou depois de uma longa ausência.
Ele também é o evento derivado de menor prioridade. Quando a mesma atualização confirma um e-mail ou converte um usuário anônimo em conta permanente, o Brew emite esse evento no lugar do auth.user.signed_in.
Para enviar um e-mail de acompanhamento a usuários inativos, decida na sua aplicação quem está inativo, com base nos dados de atividade dela. Dispare um evento personalizado separado no Brew só para os usuários que se encaixam nesse critério e deixe que uma automação ativa envie o acompanhamento a partir desse evento.
Teste os dois caminhos: um usuário inativo recebe o acompanhamento; um usuário que estava ativo antes da verificação não recebe.
Os eventos auth.user.created, auth.user.updated e auth.user.deleted vêm de inserções, atualizações e exclusões em auth.users. O Brew deriva os demais eventos de uma atualização, comparando a linha antiga com a nova.
Uma atualização gera um único evento. Quando várias colunas mudam juntas, vale a primeira correspondência, nesta ordem: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Uma atualização que não corresponde a nenhum desses casos chega como auth.user.updated.
O Brew é compatível com estes 12 tipos de evento:
Cada evento verificado com um endereço de e-mail real cria ou atualiza um contato do Brew, identificado pelo e-mail, independentemente de alguma automação usar o evento. Quando o evento traz esses dados, o Brew preenche o nome, o sobrenome e os campos supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url e supabase_provider.
Alguns eventos também preenchem campos de ciclo de vida. O campo supabase_account_status passa a ser active, invited, banned ou deleted. Os campos supabase_email_verified_at, supabase_phone_verified_at e supabase_last_sign_in_at vêm dos eventos de confirmação e de login correspondentes.
Use o esquema de payload declarado do evento selecionado para as tags de mesclagem. Todos os eventos incluem email e, quando presentes, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt e emailConfirmedAt. Os nomes e os avatares vêm de raw_user_meta_data, com alternativas para cadastros via OAuth. Os três timestamps usam o tempo Unix, em segundos.
Os eventos derivados acrescentam previousValue, newValue ou os dois, com o valor antigo e o novo da coluna em texto. O auth.user.password_changed não tem nenhum dos dois. O campo provider guarda o método de cadastro, como email, google ou github, para você direcionar os fluxos de boas-vindas conforme a forma como a pessoa se cadastrou.
O ID de usuário do Supabase não é uma tag de mesclagem. O Brew guarda esse ID no contato, no campo supabase_user_id, para filtros e segmentação.
Uma conta no Supabase não estabelece consentimento para e-mails de marketing. Registre o consentimento no cadastro e confira-o antes de envios promocionais.
Não. O Supabase Auth continua enviando links de confirmação, links mágicos, convites e redefinições de senha pela própria configuração de e-mail, como um SMTP personalizado. O Brew inicia automações depois que essas mudanças chegam a auth.users. O Supabase recomenda domínios de envio separados para os e-mails de autenticação e os de marketing.
Receber um evento e enviar um e-mail são etapas separadas. Confirme que uma automação correspondente está ativa, examine os filtros e o histórico de execuções dela e verifique a elegibilidade do destinatário e o domínio de envio. Um evento de um usuário sem endereço de e-mail, como um usuário anônimo que ainda não informou um, não cria nenhum contato nem inicia nenhuma automação.
