Migrar da Resend para a Postal

Cadastre o domínio no painel e crie os registros de DNS que ele mostra. Dá para manter o mesmo domínio na Resend e na Postal ao mesmo tempo: os registros são diferentes, porque a Postal usa o seletor postal no DKIM.

• A Postal confere os registros sozinha por até 72 horas e avisa por webhook (domain.updated)
• Se o domínio ainda não tem DMARC, os grandes provedores cobram de quem envia volume: comece com p=none e endureça depois
• Crie uma chave de API em Chaves de API. Para sistemas que só enviam, use uma chave só de envio, restrita ao domínio

Os SDKs oficiais da Resend funcionam apontando para a Postal. No Node.js, passe baseUrl ao criar o cliente ou defina RESEND_BASE_URL. O corpo do e-mail, a resposta ({"id"}) e o formato de erro (statusCode, name, message) ficam iguais.

Pelo SDK

- const resend = new Resend(process.env.RESEND_API_KEY);+ const resend = new Resend(process.env.POSTAL_API_KEY, { baseUrl: 'https://api.postal.so' });

Ou só pelo ambiente

# Sem mexer no código que já usa new Resend(chave)
RESEND_BASE_URL=https://api.postal.so
RESEND_API_KEY=ps_sua_chave

Por HTTP

- curl -X POST 'https://api.resend.com/emails' -H 'Authorization: Bearer re_...'+ curl -X POST 'https://api.postal.so/emails' -H 'Authorization: Bearer ps_...'

Por SMTP

- Servidor: smtp.resend.com- Usuário: resend- Senha: re_...+ Servidor: smtp.postal.so+ Usuário: postal (resend também é aceito)+ Senha: ps_...

Testado com o pacote resend 6.34 (Node.js): envio simples, agendado, em lote e com idempotência, consulta, edição e cancelamento, anexos, domínios, chaves de API, webhooks e webhooks.verify. Outros SDKs que deixam trocar a URL base falam o mesmo formato, mas não foram testados um a um: se encontrar uma diferença, avise pelo formulário de contato.

Antes de virar o tráfego, leve a lista de supressão, para não escrever a quem já pediu para sair, e os contatos, se você usa a audiência. Recrie também os templates: as variáveis {{{VAR}}} são as mesmas da Resend.

• Lista de supressão: POST /suppressions/batch/add, com 100 endereços por requisição
• Contatos: importação por CSV, pelo painel ou pela API
• Templates: crie e publique com o mesmo alias e as mesmas variáveis; os envios usam sempre a última versão publicada

curl -X POST https://api.postal.so/suppressions/batch/add \
  -H "Authorization: Bearer $POSTAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["[email protected]", "[email protected]"]}'

Os nomes dos eventos são os mesmos (email.delivered, email.bounced…), no formato {type, created_at, data}. O que muda é o segredo: na Postal, cada endpoint tem o seu signing_secret (whsec_…). A assinatura segue o padrão Standard Webhooks, e o resend.webhooks.verify aceita os cabeçalhos webhook-* e svix-*.

• Crie o endpoint em Webhooks (painel ou POST /webhooks) e escolha os eventos
• Envie um evento de teste pelo painel antes de virar o tráfego
• São 8 tentativas em cerca de 27 horas, sempre com o mesmo webhook-id; o reenvio manual sai pelo painel ou por POST /webhooks/{id}/events/{event_id}/replay
• Outras linguagens: veja a verificação da assinatura

import { Resend } from 'resend';

const resend = new Resend(process.env.POSTAL_API_KEY, { baseUrl: 'https://api.postal.so' });

// Lê o corpo cru da requisição, sem reformatar o JSON
const event = resend.webhooks.verify({
  payload: rawBody,
  headers: {
    id: request.headers['webhook-id'],
    timestamp: request.headers['webhook-timestamp'],
    signature: request.headers['webhook-signature'],
  },
  webhookSecret: process.env.POSTAL_WEBHOOK_SECRET, // whsec_...
});

Troque a URL base e a chave no ambiente de testes, mande um e-mail para você mesmo e acompanhe em Logs e nos webhooks. Os endereços de teste aceitam +rótulo, não usam cota, não afetam a reputação e geram webhooks reais (dependem do plano). Depois, vire em produção e deixe a Resend por perto por alguns dias.

• IDs diferentes. Os IDs de e-mails e de webhooks da Resend não existem na Postal, e o contrário também. Guarde de qual provedor cada e-mail saiu e continue recebendo eventos da Resend para o que saiu por lá
• Marque a origem. Use tags (por exemplo, provider: postal) e uma Idempotency-Key própria em cada envio
• Um provedor por vez no mesmo fluxo. Convites, redefinições de senha e códigos devem sair por um só caminho. Olhe os bounces nos primeiros dias, porque o limite de reputação vale para o time inteiro
• Endereço que voltou a funcionar. Um bounce permanente põe o endereço na lista de supressão; remova com DELETE /suppressions/{id} ou POST /suppressions/batch/remove