Send Real Emails From Any AI-Built Website or Web App

Plan the Email

Start with one event that already works in your app — for example a form submission, booking, order, application, signup, or status change.

Plan the Email

Choose what should trigger the email, who should receive it, and what information the message should include.

I want to add one real transactional email to this existing website or web app. The event is: {{EMAIL_TRIGGER}} The recipient should be: {{EMAIL_RECIPIENT}} The email should: {{EMAIL_PURPOSE}} Useful details to include: {{EMAIL_DETAILS}} Do not modify any files in this task. Before changing anything, inspect the existing project and find the real event and data flow that match this request. Determine: - Where this event actually happens in the project - Whether the main action already works correctly today - Which code or backend/server-side path handles the event - Where the real event data is available at that point - Which email address should be used for the recipient - Which real values are safe and useful to include - Whether the project already has a secure server-side or serverless place to send email from - Whether an email-sending integration already exists that should be reused Do not rebuild the original feature. It already works and this guide only adds the notification. Do not create: - a contact form - a booking system - an order system - authentication - a newsletter, subscriber list or campaign - any other unrelated workflow Do not guess recipient email addresses. If a customer or user email is required but the existing event does not actually provide one, stop and tell me exactly what is missing rather than inventing a source for it. Do not put SMTP credentials or API keys in browser code. Then recommend: - The exact existing event to hook into - The recipient flow - A simple email subject - The essential email content, in the tone the project already uses elsewhere - Which real event values should be included - The safest existing server-side or serverless place to send from If the recipient is BOTH, plan two appropriate emails from the same event: 1. A customer or user confirmation 2. An owner or admin notification Do not send the same internal message to both audiences when the content should differ. Keep the email simple. Do not design a complex email template system. Explain the plan in beginner-friendly language, then stop and wait for my approval.

When should the email be sent?

Who should receive the email?

What should the email do?

What details should appear in the email?

Name, booking date, order number, message, status, selected service...

Review the email plan before continuing. The original app event should already work — this guide only adds the notification.

NOTE

Once this email works, you can reuse the same pattern for other events.

Choose a Sending Method

Sending method

Business email (SMTP)

Use an existing business mailbox or SMTP-enabled email service.

Resend

Use a dedicated transactional email API.

Both methods send from the server side. Never put an SMTP password or API key in browser code.

Prepare Your Sending Details

Collect what you need before the project touches anything. This follows the sending method you chose in Step 2.

Open the account where your business email lives and copy its SMTP settings. Most SMTP-enabled email providers list these in the mailbox or email-service settings.

Sign in to your email or hosting provider Open the SMTP or outgoing mail settings for your mailbox Copy the SMTP host, the port, the username and the password or app password Note the exact sender address you will be sending from

IMPORTANT

Keep these values somewhere private for now. They go into environment variables in the next task — never into the project's code.

Set Up a Professional Email Address for Your Website Domain

No business mailbox yet? Create one there first, then come back to this step.

/video/set-up-a-professional-email-address-for-your-website-domain

Create the Resend account and the sender identity you will send from. You are only preparing the account here — the project is connected in the next task.

Open Resend

Create the account and the API key you will use for sending.

https://resend.com

Create a Resend account Generate an API key and copy it somewhere private Add the sender domain you want to send from Complete the domain verification Resend asks for, if it is required for your sender

IMPORTANT

Keep the API key private. It goes into an environment variable in the next task — never into the project's code.

Set Up Sending in the Project

Build the sender only, using the method you chose in Step 2. The real app event is connected in the next section.

Set Up SMTP Sending

Connect the project's server-side email sender to your existing business email without exposing the SMTP credentials.

Using the email plan we already approved, set up secure SMTP email sending in this project. Do not connect the application event yet. First inspect the project's existing framework, backend and server or serverless patterns, and use the smallest implementation that fits what is already there. Requirements: - Send email only from a trusted server-side or serverless environment - Reuse the project's existing server architecture wherever possible - Store the SMTP values in environment variables - Never put SMTP credentials into frontend or browser code - Never hardcode the SMTP password into a committed source file - Create one reusable email-sending utility or function - Use the sender address we confirmed in the plan - Keep the implementation compatible with the project's existing runtime - Do not redesign the app - Do not add unrelated email features - Do not build a queue - Do not build retry infrastructure - Do not add newsletter, subscriber or campaign behaviour I will supply the SMTP host, port, username, password and sender address through the project's normal environment-variable setup. Do not invent any of those values. If this project has no safe server-side or serverless place for this code, do not work around it by putting credentials in the browser. Inspect the stack, choose the smallest safe server-side approach that is genuinely compatible with it, and if a prerequisite is unavoidable, explain exactly what it is and stop. Do not build a large custom backend for one email. When you are done, tell me: - Which environment variable names are required - Where those values belong for this project - Which server-side file or function handles sending - How I can confirm the SMTP connection is ready - What still needs to be connected in the next step Do not trigger any real application email yet, unless a minimal safe transport test is genuinely needed to confirm the connection.

Set Up Resend

Connect Resend through the project's existing server-side setup without exposing the API key.

Using the email plan we already approved, set up secure transactional email sending with Resend. Do not connect the application event yet. First inspect the project's current framework and server or serverless setup, and use the smallest implementation that fits what is already there. Requirements: - Use the current recommended server-side Resend SDK or API pattern appropriate to this project - Store the Resend API key in an environment variable - Never expose the API key in frontend or browser code - Reuse the project's existing backend or serverless architecture wherever possible - Create one reusable email-sending utility or function - Use the sender identity we confirmed in the plan - Do not redesign the app - Do not assume this project is a booking site, and do not introduce booking tables, appointment fields or booking-specific function names - Do not assume a particular database or backend provider — use whatever this project actually has - Do not add unrelated email features - Do not build queues or retry infrastructure - Do not add newsletter, subscriber or campaign behaviour If this project has no safe server-side or serverless place for this code, do not work around it by putting the API key in the browser. Inspect the stack, choose the smallest safe server-side approach that is genuinely compatible with it, and if a prerequisite is unavoidable, explain exactly what it is and stop. Do not build a large custom backend for one email. When you are done, tell me: - Which environment variable names are required - What sender or domain requirement still needs to be completed, if any - Which server-side file or function handles sending - How I can confirm the sender is ready - What still needs to be connected in the next step Do not connect the real application event yet.

Connect the Email Trigger

Now join the two halves: the event that already works, and the sender you just built.

Connect the Email Trigger

Connect the real app event to the email sender using real data while keeping the original workflow working normally.

Using the email plan we approved and the email sender we already configured, connect the existing application event to the transactional email. The selected email transport is: {{selection:emailTransport|Not chosen yet — ask me whether this project sends through an existing business email over SMTP or through the Resend API before you change anything.}} Use the REAL event already present in the project. Do not rebuild the original feature. Requirements: - Trigger the email only after the main application action reaches its successful state - Use real event and record data, never placeholder or sample values - Use the correct recipient from the approved plan - Use a clear, specific subject - Include only the useful, appropriate real values we agreed on - Handle user-provided values safely when they are placed into the message - Keep provider credentials and server secrets out of browser code - Do not add newsletter, subscriber, campaign or marketing behaviour - Do not add unrelated automations Recipient behaviour: If the email goes to the customer or user: - Use the real email address available from the event - Confirm a recipient address actually exists before attempting to send - Do not invent addresses - Do not include internal or admin-only information If the email goes to the owner or admin: - Use a trusted server-side configured destination, or the project's existing owner-notification pattern - Do not expose the owner address or its configuration in browser code If the email goes to BOTH, create two messages from the same event: 1. The customer or user email: an acknowledgement or confirmation, with the details that person needs 2. The owner or admin email: a notification that something happened, with the operational details needed to act Do not send identical internal information to both recipients. Email failure behaviour, and this part matters most: The core application action must not break merely because sending a notification email failed. If the submission was saved, the booking created, the order placed or the status changed successfully, a mail-provider failure must not undo that — unless the project's existing business logic explicitly requires delivery to be part of that transaction. - Catch email-provider errors using the project's existing error patterns - Do not let a failed send white-screen or crash the page - Do not show SMTP or API details to the user - Preserve an already-successful main action - Log or report enough for me to debug a failure - Do not build queues, retries or monitoring in this task If sending the email IS the main action of this feature, say so and use the appropriate failure behaviour for that case instead of applying the non-blocking rule blindly. Email content: Keep it simple. Plain text or simple HTML is enough. Do not introduce React Email, MJML, a template library or a branding system unless this project already uses one and reusing it is genuinely simpler than adding anything new. When you are done, report: - Which real app event triggers the email - Which server-side function or file sends it - Which transport is active - Who receives it - Which real values are included - How email errors are handled - Which files changed

Test It Yourself

Run the real thing once, like a real customer would.

Trigger the real event once

Confirm the original app action still succeeds

Confirm the intended recipients receive the correct email

Open the email and confirm the sender and the real event details are correct

Trigger the event once more and confirm one event does not create unintended duplicate emails

Verify the Email Workflow

Verify the Email Workflow

Check real delivery, secret handling, recipient logic, and that an email failure does not break the main app action.

Run a focused verification of the transactional email we just added. The active email transport is: {{selection:emailTransport|Not chosen yet — ask me whether this project sends through an existing business email over SMTP or through the Resend API before verifying anything.}} Verify: - The email is triggered by the intended event only - The main app action still works normally - The correct recipient receives the message - Real event values are used - No fake or placeholder demo data remains anywhere in the message - SMTP credentials and API keys remain server-side - Nothing secret appears in client or browser code - Repeating one event does not cause unintended duplicate sends - No newsletter, subscriber or campaign behaviour was introduced Then check the failure path by reading the code, not by breaking my setup: - Email sending is wrapped in the project's existing error handling - A provider error cannot white-screen or crash the page - A provider error cannot undo or roll back an already-successful main action - SMTP or API details are never shown to the user - A failed send is logged or reported well enough to debug If this project already has a local or test environment where a failed send can be simulated safely and without touching live configuration, run that check and tell me what you observed. If it does not, say so and rely on the code review above instead. Do not ask me to break a working production credential to complete this verification. Do not build retry or monitoring infrastructure. Do not broaden this into a full security audit of the project. If something in this email workflow is genuinely broken, fix only that. When you are done, report: - Whether real sending works - Which transport is active - Whether the email uses real event data - Whether recipient behaviour is correct - How an email failure is handled, and how you verified it - Whether secrets remain server-side - Whether anything directly related is still broken

Trigger the real event one last time. The app action and the email should both complete normally.