Back to Forms and Auth

Turn a form into a reliable handoff.

A contact form should validate input, save a submission safely, show an honest status and notify the intended recipient through a traceable email path. Treat the database and notification as separate steps.

Forms and Auth · 8 min read · Updated 2026-06-06

Use a two-stage flow

The steps below walk through this one stage at a time. Complete each step before continuing so nothing gets missed.

  1. Validate and normalise fields in the client for fast feedback.
  2. Insert through a policy or server-side function that validates again.
  3. Return a clear saved state without exposing internal details.
  4. Queue or send the notification from a trusted server boundary.
  5. Log delivery status and handle failure without losing the submission.
  6. Test duplicate submits, invalid input and provider failures.

Alongside that flow, a few rules protect the submission and the recipient.

  • Never put an email provider API key in client code.
  • Do not trust hidden fields for recipient or permissions.
  • Do not show a success message when only the browser request completed.
The saved submission is the source record. The email is a notification that can be retried and audited.

Pre-launch checklist

This comes down to a handful of concrete details. Work through the list below and flag the ones you have not covered yet.

  • Rate limiting or basic spam protection is in place.
  • Failed email sends do not delete or lose the saved submission.
  • Recipient address is configured server-side, not passed from the client.
  • Confirmation state is only shown after the database insert succeeds.
  • A test submission has been traced end to end from form to inbox.

Handover notes for the client

Use the list below as a working checklist. Each item is something you can verify or action directly on your own site.

  • Where submissions are stored and how to export them.
  • Who receives the notification email and how to change that recipient.
  • What happens to a submission if the notification email fails.

Questions

Save to the database first. If the email notification fails afterwards, the submission is not lost and can be retried or reviewed later.

Combine basic measures such as honeypot fields, rate limiting per IP and server-side validation before relying on more intrusive checks that could block genuine visitors.

No. Email provider credentials must stay server-side in a secret or edge function. Sending directly from the client would expose the API key to anyone who inspects the page.

Want your app built properly?

We take Lovable prototypes to production: secure data, real auth and a clean deploy.

See the service

Related guides

Lovable forms to Supabase

A production Lovable form validates at the boundary, saves to a protected table and gives the visitor a clear result. Email notifications are a second step, not proof that the database write succeeded.

Lovable form validation, file uploads and email notifications

Lovable form validation, file uploads (size, type, storage policy) and email notifications with delivery monitoring and retries, done properly.

Lovable APIs, secrets and edge functions

Put private API keys and privileged workflows behind backend functions. The browser can call a controlled endpoint, but it should never receive a secret that grants access to another service.