Connect an email service and send a real test email
Connect a proper email delivery service so your app can send confirmations, receipts and other real messages reliably.
When to use this
Before relying on your app to send confirmations, receipts, password emails or other messages people expect to receive.
Before you start
- An account with the email service you chose. If you have not chosen one, ask the builder which supported provider fits simple transactional email.
- A sender name, from address and reply-to address.
- Access to your domain settings if the provider asks you to verify the sending domain. Verification proves you are allowed to send from that domain.
- A private API key from the provider and one email address you control for testing. Never paste the key into a public page or screenshot.
The prompt
This app needs to send real emails after [ACTION, e.g. a booking is confirmed or an order is placed]. Connect it to [EMAIL SERVICE] and set up one complete email flow before adding any others. The outcome is that when [EXACT TRIGGER] happens successfully, the app sends one email to [RECIPIENT, e.g. the customer email saved with the booking]. Send it from [SENDER NAME] at [FROM EMAIL], with replies going to [REPLY-TO EMAIL]. The subject should be [SUBJECT OR SUBJECT PATTERN], and the message should include [DETAILS THE RECIPIENT NEEDS]. An API key is a private password that lets this app use the email service. Store that key only in the platform's secure settings, never in a page, browser code, public file or copied message. If the service, sender address or sending domain is not ready, stop and tell me exactly what I need to connect or verify myself. Send only after the app has successfully saved the action that triggered the email. Prevent duplicate emails if a person clicks twice or the app retries. If sending fails, keep the booking, order or submission safe, show the user a calm message, and record the failure somewhere I can find without exposing private details. Use a clear, trustworthy email style that feels [WARM AND PERSONAL / SIMPLE AND PROFESSIONAL]. Include only information the recipient needs. Add a test action that sends to [MY TEST EMAIL], then tell me how to run that test and where to see whether the service accepted or rejected it.
Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.
Build it on
What this creates
- A secure connection between the app and your email provider
- One working email triggered by one clearly defined action
- A reusable email layout with your sender and reply-to details
- Duplicate protection and a visible record of failed sends
- A safe test action and plain-language testing instructions
Check it worked
Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:
- You perform the test action and receive the email at your own address
- The From name and Reply-to address are correct when you open the email
- Repeating the same saved action does not send an accidental second copy
- A failed send does not erase the booking, order or form submission that caused it
- You can find a clear success or failure entry without seeing the private API key anywhere
Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.
Next steps
Add a second transactional email
After the first email has arrived correctly
Using the same connected email service and the same safety rules, add one new email for [EXACT TRIGGER]. Send it to [RECIPIENT], include [REQUIRED DETAILS], and use [SUBJECT]. Do not change the email flow that is already working. Add a separate test for this new message.
You'll know it worked when: The second test email arrives correctly and the original email still works.
Improve delivery and sender trust
Before sending important messages to customers
Review the email connection for delivery problems. Confirm whether [FROM EMAIL] is verified, make sure the From name and Reply-to address are consistent, remove wording that looks like spam, and give me a plain-language list of any provider settings I still need to complete myself. Do not claim delivery is guaranteed.
You'll know it worked when: You know what is verified, what is not, and which manual steps remain.
Add an email activity view
Once more than one email flow exists
Add an admin-only email activity view showing when each message was attempted, its purpose, recipient, and whether it was sent or failed. Do not store the full private message unless [I NEED THAT FOR A SPECIFIC REASON], and never show API keys. Add a retry button for failed messages that cannot send the same email twice.
You'll know it worked when: You can find a failed email and retry it safely from an admin screen.
Watch out for
- A connected account does not guarantee inbox delivery. An unverified sending domain can make messages land in spam or be rejected. Complete the provider's domain-verification steps and test with more than one inbox before launch.
- Email providers can charge separately. Check the provider's current plan, limits and overage rules before turning on a busy flow; the app builder's subscription may not include the email bill.
- Automatic retries can send duplicates. The fix is to give each real event one unique reference, such as its booking or order number, and record that its email was already sent before retrying.
- Transactional email is not a marketing mailing list. Promotions generally need consent and a working unsubscribe path. Do not quietly turn booking or account emails into advertising.
Platform notes
Base44's built-in email is the quickest option for registered app users, but emailing any outside address requires an external provider such as Resend; custom-domain and automatic-sending features can also depend on the plan. Lovable has a Resend connector, which is a built-in connection that uses your own Resend account and key, with sending billed by that provider. On v0, email usually runs through an external provider from private code that visitors cannot see, with its key stored in secure Vercel project settings, so setup is more hands-on.
Spend fewer credits
Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.
- Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
- Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
- Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
- One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
- Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
- Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.
The prompts on this page are written to do most of this work for you — that's the point of them.
Read the full guideRelated playbooks
Related prompts
Last reviewed: 2026-07-27