Le courrier de votre produit
de l'appel au résultat
Votre app envoie un message et OpenEmail l'expédie depuis votre domaine. Chaque appel est rattaché à la clé qui l'a fait, et chaque envoi a un résultat à lire.
L'appel répond avec un identifiant de message. Chaque événement reçu par votre point d'accès porte le même.
D'où ça part
À quoi ça ressemble aujourd'hui.
Le courrier sort de votre code
Reçus, codes d'inscription et réinitialisations partent de votre backend, personne ne les tape.
Après l'envoi, plus rien
Un client dit que le code n'est jamais arrivé, et aucune trace de distribution ne permet de vérifier.
Une clé partagée, aucun journal
Tous les services envoient avec le même secret, et rien ne montre quel appel a échoué ni quand.
Comment ça marche
Opérationnel en quatre étapes.
- 01
Vérifiez votre domaine
Publiez les enregistrements affichés dans les réglages, et le domaine passe au vert dès qu'ils concordent.
- 02
Créez une clé limitée
Limitez la clé aux adresses et domaines depuis lesquels elle peut envoyer, et bornez sa portée avec un rôle.
- 03
Envoyez le message
Un appel nomme le modèle, ses valeurs et le destinataire, et une nouvelle tentative ne peut pas l'envoyer deux fois.
- 04
Prenez le webhook, lisez le journal
Votre point de terminaison reçoit chaque événement par ID du message, et le journal indique distribué, rejeté ou échec.
Sur quoi ça repose
Les éléments qui font le travail.
Cela repose sur une API documentée avec des clés limitables, un SDK typé, des webhooks vers votre point de terminaison, des modèles versionnés et les enregistrements qui soutiennent votre domaine d'envoi.
Une API HTTP documentée, avec des clés à émettre, restreindre et révoquer.
Un client TypeScript d'abord, le reste ensuite.
Prévient votre endpoint quand du courrier arrive, au lieu de vous obliger à l'interroger.
Un corps écrit une fois, versionné, et envoyé maintes fois : depuis le compositeur, depuis votre propre code ou par un agent.
Une marque à côté de l'expéditeur quand les enregistrements publiés du domaine expéditeur concordent.
Un enregistrement de départ p=none, affiché à copier ou écrit par une synchronisation, jamais durci à votre place.
v=DMARC1; p=none; rua=…
En pratique
Chaque élément, pas à pas.
Quatre pages plus courtes suivent le chemin : envoyer depuis votre code, lire le journal des appels, ce qui s'est passé après l'envoi, et le courrier dans un test, encore à venir.
Envoyez reçus, codes et liens de réinitialisation depuis votre code, et sachez quand ils arrivent.
Chaque appel d'une clé, chaque webhook envoyé, avec le code et la durée.
Donnez à chaque test sa propre adresse et lisez le courrier qu'il reçoit.
Questions
Posées avant de s'inscrire.
Qu'est-ce qui empêche un renvoi d'expédier deux fois ?
Un appel nomme le modèle, ses valeurs et le destinataire, et le rejouer n'envoie pas deux fois. L'appel répond avec un ID du message, et chaque événement reçu par votre point de terminaison porte ce même ID.
Puis-je voir ce qui s'est passé après l'envoi ?
Oui. Chaque envoi se lit distribué, rejeté, plainte ou échec, par jour, source et adresse d'envoi, et le journal des requêtes garde la méthode, le chemin, le code de statut et la durée de chaque appel d'une clé.
Y a-t-il un SDK pour mon langage ?
Pas encore, dans la plupart des cas. Le client typé est d'abord TypeScript, les autres suivront : pour l'instant, tout autre langage appelle directement l'API HTTP documentée.
À proximité
D'autres tâches pour la même boîte.
Chaque ticket, fiche ou client peut avoir son adresse. Le courrier envoyé là atteint votre point de terminaison en événement signé, et votre code répond depuis cette adresse.
Donnez à un agent sa propre adresse et une clé limitée à ce qu'il peut faire. Il lit, étiquette, rédige et envoie, et chacun de ses appels est journalisé.
Écrivez-le une fois comme modèle. Envoyez-le depuis l'éditeur, depuis votre code ou le jour de votre choix, puis lisez ce qui s'est passé.
