O e-mail que o seu produto envia
da chamada ao resultado
O seu app posta uma mensagem e o OpenEmail a envia do seu próprio domínio. Cada chamada fica registrada na chave que a fez, e cada envio tem um resultado para ler.
A chamada responde com um id de mensagem. Cada evento que o seu endpoint recebe traz o mesmo id.
Onde começa
Como isso é hoje.
O e-mail sai do seu código
Recibos, códigos de cadastro e redefinições de senha são enviados pelo seu backend, não digitados por uma pessoa.
Depois do envio, nada volta
Um cliente diz que o código nunca chegou, e não há registro de entrega para conferir.
Uma chave só, sem registro de chamadas
Todo serviço envia com o mesmo segredo, e nada mostra qual chamada falhou nem quando.
Como funciona
Funcionando em quatro passos.
- 01
Verifique o seu domínio
Publique os registros mostrados nas configurações, e o domínio fica verde quando eles conferirem.
- 02
Emita uma chave limitada
Limite a chave aos endereços e domínios de onde ela pode enviar, e restrinja o que ela alcança com uma função.
- 03
Poste a mensagem
Uma chamada nomeia o modelo, os seus valores e o destinatário, e uma nova tentativa não envia duas vezes.
- 04
Receba o webhook, leia o registro
O seu endpoint ouve cada evento pelo id da mensagem, e o registro mostra entregue, devolvido ou com falha.
Em que se apoia
As partes que fazem o trabalho.
Se apoia numa API documentada com chaves limitáveis, um SDK tipado, webhooks para o seu endpoint, modelos com versão, e os registros que sustentam o seu domínio de envio.
Uma API HTTP documentada, com chaves que se emitem, se limitam e se revogam.
Primeiro um cliente TypeScript, depois os restantes.
Avisa o seu endpoint quando chega correio, em vez de o obrigar a sondar.
Um corpo escrito uma vez, versionado, e enviado muitas vezes: a partir do editor, do seu próprio código, ou por um agente.
Uma marca ao lado do remetente quando os registos publicados do domínio remetente batem certo.
Um registo inicial p=none, impresso para copiar ou escrito por uma sincronização, nunca apertado em seu lugar.
v=DMARC1; p=none; rua=…
Na prática
Cada parte, passo a passo.
Quatro páginas mais curtas percorrem o caminho: enviar do seu código, ler o registro de chamadas, o que aconteceu depois do envio, e e-mail dentro de uma rodada de testes, que ainda está por vir.
Envie recibos, códigos e links de redefinição a partir do seu código e saiba quando chegam.
Cada chamada de uma chave, cada webhook enviado, com o código e o tempo.
Dê a cada teste o seu próprio endereço e leia o e-mail que ele recebe.
Perguntas
Feitas antes do cadastro.
O que impede uma nova tentativa de enviar o mesmo e-mail duas vezes?
Uma chamada nomeia o modelo, os seus valores e o destinatário, e repeti-la não envia duas vezes. A chamada responde com um id de mensagem, e todo evento que o seu endpoint ouve carrega esse mesmo id.
Consigo ver o que aconteceu depois do envio?
Sim. Cada envio aparece como entregue, devolvido, com reclamação ou com falha, por dia, origem e endereço de envio, e o registro de requisições guarda o método, o caminho, o código de status e a duração de cada chamada que uma chave fez.
Existe um SDK para a minha linguagem?
Na maioria dos casos, ainda não. O cliente tipado é TypeScript primeiro e os outros vêm depois, então por ora toda outra linguagem chama a API HTTP documentada diretamente.
Por perto
Outros trabalhos para a mesma caixa.
Cada chamado, registro ou cliente pode ter um endereço próprio. O e-mail enviado para lá chega ao seu endpoint como evento assinado, e o seu código responde como esse endereço.
Dê ao agente um endereço próprio e uma chave limitada ao que ele pode fazer. Ele lê, etiqueta, rascunha e envia, e cada chamada que ele faz fica registrada.
Escreva uma vez como modelo. Envie do editor, do seu próprio código ou no dia que você escolher, depois leia o que aconteceu.
