Aller au contenu

Email

Envoie des emails transactionnels depuis ton app. Gère les identités d’expéditeur et suis les livraisons depuis Admin > Email de ton app.

Chaque app Proyecta peut envoyer des emails transactionnels. Vérifie une identité d’expéditeur, puis envoie depuis le code de ton app — aucun compte chez un prestataire email séparé n’est nécessaire.

Ouvre Admin > Email dans le builder — ou /admin sur ton site publié. Elle comporte deux parties :

Partie À quoi ça sert
Identities Ajouter et vérifier des adresses email ou des domaines expéditeurs
Sent Parcourir les emails envoyés avec leur statut de livraison (envoyé, livré, bounced, etc.)

Tu peux ajouter une nouvelle identité d’expéditeur et consulter l’historique de tes livraisons — sans écrire une seule ligne de code.

  1. Crée et vérifie une identité d’expéditeur (une adresse email ou un domaine) dans ton panneau admin
  2. Envoie — depuis ton app avec useSendEmail(), ou depuis le panneau admin pour des campagnes

Envoyer depuis une adresse partagée (@proyectamail.com)

Section intitulée « Envoyer depuis une adresse partagée (@proyectamail.com) »

La solution la plus simple consiste à réserver une adresse sur le domaine d’envoi partagé de Proyecta, @proyectamail.com. Elle est vérifiée instantanément à la création — la plateforme possède déjà ce domaine, donc tu n’as aucun enregistrement DNS à configurer.

Tu fais cela dans la section Emails du panneau admin de ton app : saisis l’adresse souhaitée et elle est prête immédiatement.

Les adresses individuelles ne fonctionnent qu’avec @proyectamail.com. En demander une sur un autre domaine (ex. hello@myapp.com) sera refusé — pour envoyer depuis ton propre domaine, vérifie le domaine entier à la place (voir ci-dessous). Chaque adresse partagée est réservée globalement, donc deux apps ne peuvent pas envoyer depuis le même expéditeur @proyectamail.com.

Pour envoyer depuis ton propre domaine — depuis n’importe quelle adresse de ce domaine (hello@, support@, noreply@, etc.) — vérifie le domaine entier. Contrairement à une adresse partagée @proyectamail.com, un domaine personnalisé ne se vérifie pas instantanément.

Ajoute le domaine dans la même section Emails. Il s’enregistre auprès du prestataire email et t’affiche les enregistrements SPF, DKIM et DMARC à publier dans ton DNS. L’expéditeur reste en statut pending jusqu’à ce que ces enregistrements se propagent et soient confirmés par le prestataire, puis passe à verified — utilise le bouton de revérification après les avoir publiés.

La vérification de domaine par DNS est entièrement implémentée — les enregistrements sont générés par le prestataire et chaque revérification interroge à nouveau leur statut.

Dans les coulisses : Proyecta authentifie ton domaine d’envoi auprès de son prestataire d’identité email (Resend) et achemine tes messages via son prestataire transactionnel (SendGrid). Tu ne gères de compte chez aucun des deux.

Depuis les pages de ton app, tu envoies avec le hook useSendEmail(). Tu choisis un template et passes des variables ; la plateforme rend le message dans la langue de l’app et l’envoie :

import { useSendEmail } from '@/hooks/useEmail.ts';
function ConfirmButton({ booking }) {
const { send, isPending, error } = useSendEmail();
return (
<button
disabled={isPending}
onClick={() =>
send({
template: 'booking_confirmation',
variables: { date: booking.date, service: booking.service },
})
}
>
Email me the details
</button>
);
}

Remarque ce que tu ne passes pas : un destinataire, un objet ou du HTML. Chaque template déclare sa propre audience :

  • self (confirmations de réservation/commande, bienvenue) → l’adresse de l’utilisateur connecté, récupérée depuis sa session.
  • owner (owner_alert) → les admins de ton app.

Les deux nécessitent une session active. C’est intentionnel, pas un oubli : la clé publique qui authentifie l’appel est présente dans le code source de ta page, donc autoriser un envoi vers un destinataire arbitraire permettrait à n’importe qui d’utiliser ton app comme relais de spam. Pour te notifier depuis un visiteur anonyme, utilise un formulaire — les soumissions de formulaires envoient déjà un email au propriétaire et confirment à l’expéditeur automatiquement, et ce chemin n’est pas falsifiable depuis le navigateur.

Les erreurs arrivent sous forme de PlatformApiError : 401 (session requise), 403 (template non activé pour cette app), 429 (limite de débit atteinte — affiche le message et propose une nouvelle tentative), 422 (aucune adresse enregistrée).

L’onglet Sent dans ton panneau admin liste tout ce que ton app a envoyé avec son dernier événement de livraison — delivered, opened, clicked, bounced, complained — tu n’as donc généralement pas besoin de code pour cela.

Chaque entrée porte son statut — sent, delivered, opened, clicked, bounced ou complained — et tu peux ouvrir n’importe quel message pour lire exactement le HTML et le texte qui ont été envoyés. Si des livraisons échouent, c’est le premier endroit où chercher.

Tu n’as pas besoin d’écrire tout ça à la main :

  • "Verify hello@myapp.com as a sending identity."
  • "Email the customer a confirmation after they finish booking."
  • "After a successful checkout, send the customer their receipt."
  • "Show me the last 20 emails we've sent and whether they bounced."
  • L’adresse from doit être une identité vérifiée. Envoyer avec une adresse non vérifiée retourne une erreur.
  • Des limites mensuelles s’appliquent selon ton plan Proyecta.
  • Éditeur de templates — conçois des templates transactionnels visuellement dans le builder
  • Endpoint d’envoi en masse pour les mailings à grande échelle