Apps no Supabase precisam de três tipos de e-mail: autenticação, eventos do produto e ciclo de vida. Compare o que Resend, Loops, Sequenzy e Brew cobrem.
Este comparativo é publicado pelo Brew. Revisamos em 28 de setembro de 2026 a documentação dos produtos indicada nos links. É um comparativo baseado na documentação, não uma afirmação de que testamos cada plataforma na prática. Confira os limites atuais dos planos na página de preços de cada fornecedor.
Você lança o seu app no Supabase, e os primeiros usuários de fora da equipe se cadastram. Os e-mails de confirmação deles ainda passam pelo remetente padrão, que só entrega para endereços pré-autorizados, então nenhum deles recebe a confirmação. O e-mail de boas-vindas que você planejou continua sendo uma anotação na sua lista de tarefas.
Um app no Supabase envia e-mails por três motivos diferentes. Os e-mails de autenticação incluem a confirmação de cadastro, os links mágicos e as redefinições de senha. Os e-mails de eventos do produto são disparados quando algo acontece no banco de dados. As campanhas de ciclo de vida cobrem onboarding, lembretes e reconquista. Uma mesma ferramenta pode cobrir mais de um desses casos, mas o Supabase recomenda manter separados os e-mails de autenticação e os de marketing.
Este guia organiza o Resend, o Loops, o Sequenzy e o Brew de acordo com as tarefas que cada um documenta.
auth.users e emite eventos como auth.user.email_confirmed. O Sequenzy sincroniza as linhas de uma tabela que você escolhe.| Tarefa | Do que precisa | Ferramentas que documentam |
|---|---|---|
| E-mails de autenticação | Um servidor SMTP ou um auth hook chamado pelo Supabase Auth | Resend, Loops, Sequenzy |
| Eventos do produto | Mudanças no banco de dados transformadas em gatilhos | Brew (auth.users), Sequenzy (uma única tabela, à sua escolha), Loops (sincronização de contatos) |
| Campanhas de ciclo de vida | Sequências, e-mails com design, públicos | Brew, Loops, Sequenzy |
Consultamos a documentação de cada fornecedor em 28 de setembro de 2026.
O guia de SMTP do Supabase lista os limites do serviço nativo. Ele só envia para endereços pré-autorizados. O limite de envio é baixo, de 2 mensagens por hora, e pode mudar sem aviso. Não há SLA de entrega. O Supabase pede que você configure um SMTP personalizado para qualquer uso além de testes e demos.
A mesma página diz para não misturar os e-mails de autenticação com os de marketing. Use serviços separados, ou pelo menos domínios de envio separados, como auth.example.com e marketing.example.com, e mantenha conteúdo promocional fora das mensagens de autenticação.
O guia do Resend para o Supabase é uma configuração de SMTP rápida. Você usa o host smtp.resend.com, a porta 465, o usuário resend e a sua chave de API como senha, preenchidos em Authentication, no Supabase. É preciso ter um domínio verificado no Resend. A partir daí, o Supabase Auth envia pelo Resend.
O Loops documenta dois caminhos para o Supabase. Um Auth Hook faz todos os e-mails do Supabase Auth passarem pelo Loops, e o SMTP fica disponível como alternativa. Uma sincronização de contatos à parte leva os usuários do Supabase para o seu público no Loops.
O Sequenzy pode encaminhar os e-mails do Supabase Auth pelo serviço de SMTP dele. Ele configura modelos transacionais padrão para redefinição de senha, links mágicos, convites e notificações de segurança, ou você pode inserir as credenciais SMTP manualmente.
A integração do Brew com o Supabase não envia os e-mails do Supabase Auth, e o Brew não documenta um relay SMTP. Mantenha os e-mails de verificação, de link mágico e de redefinição de senha em um provedor SMTP. A API do Brew pode enviar e-mails transacionais disparados pelo seu app, como um recibo. As mensagens do próprio Supabase Auth continuam precisando de SMTP ou de um auth hook.
A integração do Brew com o Supabase executa um script de configuração que instala um trigger em auth.users. O trigger assina cada mudança com pgcrypto, envia a mudança para um webhook exclusivo do Brew com pg_net e guarda o segredo compartilhado no Supabase Vault. O Brew recebe três eventos brutos: auth.user.created, auth.user.updated e auth.user.deleted. Ele também deriva outros nove a partir de mudanças nas colunas:
auth.user.email_confirmed e auth.user.phone_confirmedauth.user.email_changed e auth.user.password_changedauth.user.signed_inauth.user.banned e auth.user.unbannedauth.user.invitedauth.user.upgraded_from_anonymousOs usuários são sincronizados como contatos com campos supabase_*, como o status da conta, o horário de verificação do e-mail e o último login. A documentação do Brew observa que as renovações de token também atualizam last_sign_in_at, então auth.user.signed_in, sozinho, não é um sinal confiável de que a pessoa “voltou”.
Para eventos fora de auth.users, como project_created ou invite_sent, crie um gatilho personalizado no Brew e dispare-o a partir de uma Edge Function do Supabase. O guia do Lovable do Brew mostra esse padrão. A função lê a BREW_API_KEY dos secrets do Supabase e chama POST /v1/automations/triggers/{triggerEventId}/fire.
O Sequenzy se conecta ao Supabase via OAuth e monitora uma tabela que você escolhe, normalmente public.profiles, usando um trigger com pg_net. Ele detecta automaticamente as colunas de e-mail, ID de usuário e nome, e sincroniza as demais colunas para segmentação. Inserções emitem contact.subscribed. Atualizações renovam os atributos sem gerar evento, e exclusões emitem contact.unsubscribed. Só uma tabela por integração usa webhooks automáticos.
O Loops sincroniza os usuários do Supabase com o seu público e pode iniciar fluxos de trabalho a partir desses dados. A sincronização de contatos é configurada separadamente do caminho dos e-mails de autenticação.
O Brew gera e-mails a partir do email-design.md da sua marca, monta automações a partir de um prompt e envia do seu domínio verificado. Um fluxo de boas-vindas pode começar em auth.user.email_confirmed, para que o primeiro e-mail chegue só a quem já verificou o endereço. O Brew não tem canal de SMS e não cuida dos e-mails do Supabase Auth.
O Loops e o Sequenzy cobrem campanhas de ciclo de vida além dos e-mails de autenticação, então um único fornecedor pode cuidar dos dois. Se você seguir esse caminho, use mesmo assim domínios de envio separados para autenticação e marketing, como o Supabase recomenda.
Esta é uma divisão possível. Não a testamos de ponta a ponta.
auth.example.com.auth.users. Uma automação de boas-vindas começa em auth.user.email_confirmed.project_reminder_eligible, se ele ainda não tiver nenhum projeto. Uma automação publicada envia o lembrete a partir desse evento. Outra opção é definir e sincronizar no Brew um campo de contato booleano, has_project, e verificar contact.has_project equals false depois de uma espera. Essa condição lê o campo atual do contato no Brew; o payload original do evento não muda.Segundo o Supabase, não. O serviço padrão só envia para endereços pré-autorizados, com um limite de envio baixo, e não tem SLA. Configure um SMTP personalizado.
Não. A integração do Brew com o Supabase inicia automações a partir de mudanças em auth.users. Os e-mails de verificação e de redefinição de senha precisam de um provedor SMTP ou de um auth hook.
email_confirmed antes do e-mail de boas-vindas?Assim, as boas-vindas só chegam a endereços que funcionam, e depois do e-mail de verificação, em vez de chegarem ao mesmo tempo.
Não automaticamente. A documentação do Brew diz que todo destinatário de marketing precisa ter dado opt-in antes da importação. Registre o consentimento no cadastro e filtre por ele.
Para ver quais eventos chegam do seu projeto, conecte o Supabase no Brew, insira um usuário de teste e acompanhe o painel Eventos recentes antes de publicar um fluxo.
