Skip to main content
Resend è il servizio con cui il sito di prenotazione diretta manda all’ospite l’email “grazie, ecco la tua prenotazione” subito dopo il pagamento.
Prima di aprire un account Resend, verifica che serva davvero. Il gestionale dello studente potrebbe già mandare comunicazioni automatiche ai suoi ospiti (istruzioni di check-in, per esempio) — ma quello è diverso da una ricevuta immediata di pagamento. Per KrossBooking è verificato (30/09/2026, catalogo API completo): non ha nessun endpoint per farlo, quindi Resend serve sempre per i suoi studenti. Per un gestionale diverso, controlla la sua documentazione prima di assumere che serva lo stesso — non dare per scontato solo perché è successo con Kross.

​
Quando NON serve

Lo studente ha già un CRM (GHL) collegato in Piattaforma (vedi GHL: panoramica)? Allora la conferma può passare da lì invece che da Resend — un workflow GHL che parte alla creazione del contatto di prenotazione. Meno un servizio da collegare per lo studente. Verifica con connessione_ghl_stato prima di chiedergli di creare un account Resend che potrebbe non servire.

​
Collegamento

1

Lo studente crea l'account Resend

resend.com → sign up. Piano gratuito: 3.000 email/mese, ampiamente sufficiente per un sito di prenotazione diretta.
2

Verifica il dominio

Resend → Domains → Add Domain: inserisce il proprio dominio (es. solisera.it, o un sottodominio dedicato come mail.solisera.it — consigliato per non rischiare la reputazione del dominio principale). Resend genera record DNS (SPF, DKIM, opzionale DMARC) da aggiungere dallo stesso posto dove si è già impostato il sottodominio del sito (stesso pannello DNS, stessa persona). Senza questo passo le email escono ma finiscono in spam o vengono rifiutate.
3

Genera la API key

Resend → API Keys → Create API Key. Permesso: Sending access basta, non serve full access.
4

Consegna la chiave al team

La chiave (re_...) va nel Vault/env del progetto, mai in chat, stesso trattamento delle altre credenziali dello studente. Sul progetto Vercel del sito: RESEND_API_KEY, più EMAIL_FROM (es. Solisera <noreply@mail.solisera.it> — deve usare il dominio appena verificato) e EMAIL_REPLY_TO (dove arrivano le risposte degli ospiti).
Il dominio va verificato PRIMA di mandare la prima email vera. Un EMAIL_FROM su un dominio non verificato in Resend fallisce silenziosamente o finisce in spam — l’ospite che ha appena pagato non riceve niente e pensa che la prenotazione non sia andata a buon fine.

​
Dove si collega nel codice

Riferimento funzionante: mattone-direct-booking-template, src/lib/email/resend.ts (client lazy-init: una chiave mancante non rompe il build, fallisce solo al primo invio vero) + src/lib/email/templates/welcome.ts (il testo dell’email, da rebrandare per lo studente — colori, nome, contatti: stessa regola zero-residui della Fase 2). Chiamato da src/app/api/payments/confirm, AWAITED dopo la creazione della prenotazione — mai fire-and-forget, vedi Fase 4.

​
Come verificare

Prenotazione di prova con carta di test → l’email arriva davvero nella casella dell’ospite di prova (non solo success nella risposta API) → mittente e link “rispondi” sono quelli giusti, non quelli del template di partenza.