Pular para o conteúdo
supastack
Explorar a documentação
WebNext.js

For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/web/resend-email.md (or send Accept: text/markdown).

Adicionar o email com Resend

Crie uma conta Resend gratuita, verifique um domínio de envio e mude EMAIL_PROVIDER para que códigos e recibos cheguem a caixas de entrada reais.

Passo a passo para iniciantes

Pré-requisitos: a app a correr em local (Online em 5 minutos). Comece grátis — sem cartão, e o nível gratuito da Resend cobre os volumes de desenvolvimento.

Terminologia rápida: EMAIL_PROVIDER=local é o predefinido — as mensagens são escritas na página incorporada /mail-preview e nunca saem da sua máquina, o que é perfeito enquanto constrói. A Resend é o adaptador que entrega em caixas de entrada reais. EMAIL_FROM é a identidade de remetente que os templates usam; o seu endereço tem de estar num domínio que a Resend verificou. Os registos DNS são as linhas que cola no seu registrador ou na Cloudflare para que as caixas recetoras confiem no seu remetente.

O que cria: uma conta Resend, um domínio de envio verificado e uma chave de API — o passo do domínio é a única parte de espera, já que a propagação de DNS vai de minutos a horas.

Criar a conta Resend

1. Abra resend.com → Sign up, confirme o seu email e chega ao painel.

2. Comece com o nível gratuito — pode até enviar correio de teste a partir do remetente partilhado da Resend antes de ter um domínio, que é o que a secção seguinte cobre.

Verificar o seu domínio de envio

Teste rápido sem domínio: o endereço [email protected] funciona imediatamente como EMAIL_FROM — mas só entrega ao email com que se registou, nunca a utilizadores. Use-o para ver o pipeline a funcionar e depois faça a configuração real.

1. Abra Domains → Add Domain e introduza o domínio a partir do qual envia (por exemplo yourdomain.com; um subdomínio como mail.yourdomain.com também funciona e mantém os registos arrumados).

2. A Resend lista os registos DNS a criar — registos TXT DKIM mais entradas MX/SPF ou CNAME consoante a idade da conta. Adicione cada um no seu anfitrião de DNS: a página de DNS do seu registrador, ou a Cloudflare se moveu os nameservers. Na Cloudflare mantenha a nuvem do proxy cinzenta (DNS only) para os registos de correio — registos com proxy nunca verificam.

3. De volta na Resend clique em Verify. Esperado: o domínio passa a Verified. A propagação varia de minutos a um dia; a página do domínio nomeia o registo exato que ainda não resolve.

Uma vez verificado, qualquer endereço do domínio funciona como remetente — hello@, no-reply@, o que EMAIL_FROM usar — sem registo por endereço.

Criar a chave de API

1. Abra API Keys → Create API Key.

2. Permission: Sending access chega — o kit só envia. Dê à chave o nome do seu ambiente (production, local) para que uma chave de dev exposta possa ser revogada sem tocar na produção.

3. Copie a chave re_… agora — é mostrada uma vez. Perdê-la significa apenas criar outra.

Adicionar os valores à app

Preencha as linhas abaixo em apps/web/.env.local. RESEND_API_KEY é apenas do servidor — nunca NEXT_PUBLIC_/EXPO_PUBLIC_, nunca commitada; EMAIL_PROVIDER e EMAIL_FROM são configuração simples. Reinicie o servidor de desenvolvimento depois de editar.

EMAIL_FROM tem de estar no domínio verificado: [email protected] só chega ao seu próprio endereço de registo, e um domínio não verificado recebe uma rejeição 403 da Resend.

# apps/web/.env.local
EMAIL_PROVIDER=resend
EMAIL_FROM="Your Product <[email protected]>"
RESEND_API_KEY=re_…

Verificar e resolver problemas

Reinicie, abra /auth e peça um código de início de sessão para uma caixa de entrada real que controle. Esperado: a mensagem chega, e Resend → Emails mostra a entrega com estado verde — esse registo é também onde vivem os motivos de bounce e erro.

Nada enviado? Verifique que EMAIL_PROVIDER=resend ficou mesmo guardado em apps/web/.env.local e reinicie. Um 403 no registo do servidor significa que EMAIL_FROM não está no domínio verificado — ou que [email protected] foi enviado a alguém que não você.

Outro provedor mais tarde? EMAIL_PROVIDER também aceita ses (com as chaves AWS) e os transportes postmark, sendgrid, mailgun, smtp, brevo — mesmo contrato EMAIL_FROM, nomes env diferentes, todos listados em .env.example. O guia de email compara-os.

Para continuar a configuração, leia Configurar e-mail do Amazon SES.

Perguntas frequentes

14 perguntas

O que é o supastack?

O supastack é uma base modular para construir produtos SaaS com IA. Reúne a infraestrutura comum para que possas concentrar-te nas funcionalidades próprias do teu produto.

Suporta web e mobile?

Sim. O supastack inclui apps Next.js e Expo como pontos de partida para experiências web e mobile.

Que autenticação está incluída?

O Better Auth cobre email/palavra-passe, OTP e login social. Os workspaces pessoais são aprovisionados com a conta para que os registos fiquem delimitados desde o primeiro dia.

Como é suportada a IA?

O supastack inclui IA multi-fornecedor configurável, registo de utilização, orçamentos e suporte encriptado de chaves próprias (BYOK).

Como são geridas as subscrições?

Para produtos construídos sobre o kit, a faturação Stripe, as subscrições e as permissões formam a base do acesso pago. Os segredos de fornecedor ficam no servidor.

Onde vive o código próprio do meu produto?

As funcionalidades próprias do produto ficam num codebase separado, enquanto o produto configura e integra os módulos base do supastack.

Como funciona o preço do supastack?

O kit é uma compra única com atualizações vitalícias: Uma framework por 249 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 349 $) ou Todas as frameworks (Next.js, iOS, Android) por 499 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 599 $), mais 75 $ por lugar de programador adicional. Sem subscrição do kit. O checkout neste site entrega a tua chave de licença por email, com acesso ao repo por convite GitHub.

Como é que os workspaces delimitam os meus dados?

Os registos do utilizador são delimitados por workspaceId. Identidade, permissões, utilização de IA, eventos de faturação e entradas de auditoria ficam dentro do limite do workspace pessoal.

Como funcionam os jobs em segundo plano?

O Trigger.dev é o runtime de jobs explícito. O contrato JobRunner só promete enqueue, status e cancel — a semântica de workflow permanece específica e explícita do Trigger.dev.

Como difere o email da divulgação?

O email transacional cobre fluxos de produto como avisos de conclusão de tarefas. A divulgação fria e as campanhas pertencem ao próprio produto, fora do módulo de email deste kit.

Como funcionam as compras no aplicativo móvel?

O aplicativo móvel inclui compras nativas e restauração via RevenueCat, com acesso verificado pelo servidor. Configure as contas das lojas e conclua os testes em dispositivos antes de publicar. A cobrança web permanece separada.

Onde residem as chaves dos fornecedores de IA?

As credenciais BYOK são encriptadas e ficam no servidor. As chaves são higienizadas nos logs; a utilização e os orçamentos ficam visíveis ao nível do workspace.

Quais métodos de pagamento o checkout aceita?

O checkout hospedado na Stripe aceita cartões e também pode oferecer Alipay e WeChat Pay quando essas carteiras estiverem ativadas na conta Stripe — útil para compradores na China. As autorizações de carteira são confirmadas de forma assíncrona, então a página da licença é atualizada assim que o pagamento é liquidado.

Posso solicitar um reembolso?

Depois de obter acesso ao repositório, o supastack é seu para sempre, portanto não pode ser reembolsado. Mas fique tranquilo: você recebe o código-fonte completo com atualizações vitalícias para criar e lançar produtos ilimitados para você ou seus clientes. Você apenas não pode revender o código nem redistribuir o repositório como starter kit ou modelo.

PT
Tema