Contact Form Backend API

A contact form usually has frontend validation: required fields, email format checks, disabled submit button, and message length limits. A common beginner mistake is assuming that this is enough. It is not. Anyone can bypass browser validation, send a direct request with Postman, use curl, or submit malformed data from another script. The backend must validate every request again before sending an email.

Server-side validation protects the email service, prevents messy inbox messages, and gives the frontend predictable error feedback. At minimum, the API should validate required fields, trim whitespace, check email format, limit message length, and reject suspiciously empty or oversized submissions. The frontend can still validate for good user experience, but the backend is the final gatekeeper.

This is especially important for frontend developers learning Node.js. It teaches a core backend rule: never trust client input. The frontend helps users submit good data; the backend protects the system from bad data.

Problematic route:

          app.post("/api/contact", async (request, response) => {
            const { name, email, message } = request.body;

            await sendEmail({
              name,
              email,
              message
            });

            response.json({
              success: true
            });
          });

This route sends whatever it receives. Empty messages, invalid emails, very long content, or missing fields can still reach the email layer.

Better validation schema:

          type ContactFormInput = {
            name: string;
            email: string;
            subject?: string;
            message: string;
          };

          type ValidationResult =
            | { isValid: true; value: ContactFormInput }
            | { isValid: false; errors: Record<string, string[]> };

          function validateContactForm(body: Record<string, unknown>): ValidationResult {
            const errors: Record<string, string[]> = {};

            const name = typeof body.name === "string" ? body.name.trim() : "";
            const email = typeof body.email === "string" ? body.email.trim() : "";
            const subject = typeof body.subject === "string" ? body.subject.trim() : "";
            const message = typeof body.message === "string" ? body.message.trim() : "";

            if (!name) {
              errors.name = ["Name is required."];
            }

            if (!email || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
              errors.email = ["Enter a valid email address."];
            }

            if (!message) {
              errors.message = ["Message is required."];
            }

            if (message.length > 2000) {
              errors.message = ["Message must be 2000 characters or fewer."];
            }

            if (Object.keys(errors).length > 0) {
              return {
                isValid: false,
                errors
              };
            }

            return {
              isValid: true,
              value: {
                name,
                email,
                subject,
                message
              }
            };
          }

Validated route:

          app.post("/api/contact", async (request, response, next) => {
            try {
              const validation = validateContactForm(request.body);

              if (!validation.isValid) {
                return response.status(400).json({
                  error: {
                    code: "VALIDATION_ERROR",
                    message: "Please correct the highlighted fields.",
                    status: 400,
                    details: validation.errors
                  }
                });
              }

              await contactService.sendContactMessage(validation.value);

              response.status(200).json({
                data: {
                  message: "Your message has been sent successfully."
                }
              });
            } catch (error) {
              next(error);
            }
          });

Pay attention to: Frontend validation improves usability, but backend validation protects the API. Always validate contact form data on the server before sending emails.

A contact form backend is usually consumed by a frontend app built with React, Vue, Svelte, Angular, or plain JavaScript. A common mistake is returning inconsistent responses. One request returns { success: true }, another returns plain text, another returns { message: "Error" }, and validation failures return a different structure again. This forces the frontend to write custom parsing logic for every case.

A beginner-friendly API should still have a professional response contract. Successful requests can return { data }. Failed requests can return { error }. Validation errors can include field-level details. This makes frontend code simple: if data exists, show success; if error.details exists, map field errors into the form.

Correct HTTP status codes also matter. Use 200 or 201 for successful submissions, 400 for validation errors, 429 for rate limiting, and 500 for unexpected server problems. Do not return 200 for failed submissions.

Problematic responses:

          response.send("Message sent");

          response.status(200).json({
            error: "Invalid email"
          });

          response.status(500).json({
            success: false
          });

These responses are difficult for the frontend to handle consistently.

Better success response:

          {
            "data": {
              "message": "Your message has been sent successfully.",
              "submittedAt": "2026-06-19T12:00:00.000Z"
            }
          }

Better validation error:

          {
            "error": {
              "code": "VALIDATION_ERROR",
              "message": "Please correct the highlighted fields.",
              "status": 400,
              "details": {
                "email": ["Enter a valid email address."],
                "message": ["Message is required."]
              }
            }
          }

Frontend handling example:

          async function submitContactForm(values) {
            const response = await fetch("/api/contact", {
              method: "POST",
              headers: {
                "Content-Type": "application/json"
              },
              body: JSON.stringify(values)
            });

            const result = await response.json();

            if (!response.ok) {
              return {
                status: "error",
                message: result.error.message,
                fieldErrors: result.error.details || {}
              };
            }

            return {
              status: "success",
              message: result.data.message
            };
          }

Pay attention to: A contact form API should be easy for the frontend to consume. Use consistent success and error shapes across all responses.

Email integration usually requires sensitive values: SMTP host, port, username, password, sender address, recipient address, and sometimes API keys. A common mistake is writing these values directly inside server.js or committing them to GitHub. This creates a security risk and makes deployment harder because every environment needs different configuration.

A better backend reads configuration from environment variables. The source code should define which variables are required, but the actual secrets should live in a .env file locally and in hosting provider settings in production. The .env file should not be committed to the repository.

This is an excellent lesson for frontend developers moving into Node.js. Browser code cannot safely hide secrets, but backend code can read environment variables and keep credentials away from the client. The contact form backend is a simple project where this boundary becomes very clear.

Problematic configuration:

          const transporter = nodemailer.createTransport({
            host: "smtp.gmail.com",
            port: 587,
            auth: {
              user: "This email address is being protected from spambots. You need JavaScript enabled to view it.",
              pass: "my-real-password"
            }
          });

          const recipientEmail = "This email address is being protected from spambots. You need JavaScript enabled to view it.";

This exposes secrets in source code and makes the project unsafe to publish.

Better environment configuration:

          SMTP_HOST=smtp.example.com
          SMTP_PORT=587
          SMTP_USER=This email address is being protected from spambots. You need JavaScript enabled to view it.
          SMTP_PASSWORD=replace-with-real-secret
          MAIL_FROM=This email address is being protected from spambots. You need JavaScript enabled to view it.
          MAIL_TO=This email address is being protected from spambots. You need JavaScript enabled to view it.
          FRONTEND_ORIGIN=https://example.com

Config module:

          type AppConfig = {
            smtpHost: string;
            smtpPort: number;
            smtpUser: string;
            smtpPassword: string;
            mailFrom: string;
            mailTo: string;
            frontendOrigin: string;
          };

          function getRequiredEnv(name: string): string {
            const value = process.env[name];

            if (!value) {
              throw new Error(`Missing environment variable: ${name}`);
            }

            return value;
          }

          export const config: AppConfig = {
            smtpHost: getRequiredEnv("SMTP_HOST"),
            smtpPort: Number(getRequiredEnv("SMTP_PORT")),
            smtpUser: getRequiredEnv("SMTP_USER"),
            smtpPassword: getRequiredEnv("SMTP_PASSWORD"),
            mailFrom: getRequiredEnv("MAIL_FROM"),
            mailTo: getRequiredEnv("MAIL_TO"),
            frontendOrigin: getRequiredEnv("FRONTEND_ORIGIN")
          };

Nodemailer transporter:

          const transporter = nodemailer.createTransport({
            host: config.smtpHost,
            port: config.smtpPort,
            secure: config.smtpPort === 465,
            auth: {
              user: config.smtpUser,
              pass: config.smtpPassword
            }
          });

Pay attention to: Never commit real email credentials. Use environment variables, keep .env out of Git, and validate required configuration at startup.

Contact forms are a common spam target. If your API accepts unlimited requests from any origin, bots can abuse the endpoint and flood the site owner's inbox. A beginner implementation often focuses only on making the form send one successful email, but a production-style backend must also think about abuse prevention.

A basic contact form API should include CORS configuration, rate limiting, request size limits, and optionally CAPTCHA verification or a honeypot field. CORS alone is not a complete security solution, but it helps control which browser origins can call your API. Rate limiting helps reduce repeated submissions from the same IP address. Request size limits prevent unexpectedly large payloads.

For a frontend developer, this is a practical introduction to backend security. The frontend form can add a hidden honeypot field or CAPTCHA token, while the backend must verify and enforce the protection.

Problematic setup:

          app.use(cors());

          app.use(express.json());

          app.post("/api/contact", contactController.send);

This allows any browser origin and does not limit request frequency or request size.

Better Express setup:

          import cors from "cors";
          import rateLimit from "express-rate-limit";

          app.use(
            cors({
              origin: config.frontendOrigin,
              methods: ["POST"],
              credentials: false
            })
          );

          app.use(
            express.json({
              limit: "20kb"
            })
          );

          const contactFormLimiter = rateLimit({
            windowMs: 15 * 60 * 1000,
            max: 5,
            standardHeaders: true,
            legacyHeaders: false,
            message: {
              error: {
                code: "RATE_LIMITED",
                message: "Too many messages. Please try again later.",
                status: 429
              }
            }
          });

          app.post("/api/contact", contactFormLimiter, contactController.send);

Simple honeypot check:

          function rejectBots(request, response, next) {
            if (request.body.website) {
              return response.status(400).json({
                error: {
                  code: "INVALID_SUBMISSION",
                  message: "Invalid form submission.",
                  status: 400
                }
              });
            }

            next();
          }

          app.post(
            "/api/contact",
            contactFormLimiter,
            rejectBots,
            contactController.send
          );

Frontend honeypot field:

          <input
            type="text"
            name="website"
            autocomplete="off"
            tabindex="-1"
            aria-hidden="true"
            class="hidden-honeypot"
          />

Pay attention to: A public contact endpoint needs abuse protection. Add origin control, rate limiting, request size limits, and optional bot-detection checks.

A small contact form can start with one route and one sendMail call. But even beginner projects become cleaner when email logic is separated from routing. A common mistake is placing Nodemailer transporter setup, message formatting, validation, route handling, and error responses in the same file. This makes the code harder to test and harder to reuse.

A better structure separates the contact controller from the email service. The controller receives the request and returns the response. The service formats and sends the email. The configuration file creates the transporter. This structure helps frontend developers understand how backend responsibilities are organized without creating too much complexity.

This separation is also useful when requirements grow. You may later add auto-reply emails, admin copies, different email templates, logging, database storage, or webhook notifications. If the email logic is already isolated, those improvements are easier to add.

Problematic route:

          app.post("/api/contact", async (request, response) => {
            const transporter = nodemailer.createTransport({
              host: process.env.SMTP_HOST,
              port: Number(process.env.SMTP_PORT),
              auth: {
                user: process.env.SMTP_USER,
                pass: process.env.SMTP_PASSWORD
              }
            });

            await transporter.sendMail({
              from: request.body.email,
              to: process.env.MAIL_TO,
              subject: request.body.subject,
              text: request.body.message
            });

            response.json({
              success: true
            });
          });

This creates the transporter inside the route and mixes request handling with email infrastructure.

Better file structure:

          src/
            config/
              mail.ts
            controllers/
              contactController.ts
            services/
              contactService.ts
            validators/
              contactValidator.ts
            middleware/
              errorHandler.ts
            server.ts

Email service:

          type ContactMessage = {
            name: string;
            email: string;
            subject?: string;
            message: string;
          };

          async function sendContactMessage(input: ContactMessage) {
            await transporter.sendMail({
              from: config.mailFrom,
              replyTo: input.email,
              to: config.mailTo,
              subject: input.subject || `New message from ${input.name}`,
              text: `
          Name: ${input.name}
          Email: ${input.email}

          Message:
          ${input.message}
              `,
              html: `
                <h2>New contact form message</h2>
                <p><strong>Name:</strong> ${escapeHtml(input.name)}</p>
                <p><strong>Email:</strong> ${escapeHtml(input.email)}</p>
                <p><strong>Message:</strong></p>
                <p>${escapeHtml(input.message)}</p>
              `
            });
          }

Controller:

          async function send(request, response, next) {
            try {
              const validation = validateContactForm(request.body);

              if (!validation.isValid) {
                throw new ValidationError(validation.errors);
              }

              await contactService.sendContactMessage(validation.value);

              response.json({
                data: {
                  message: "Message sent successfully."
                }
              });
            } catch (error) {
              next(error);
            }
          }

Pay attention to: Keep route handlers focused. Put email formatting and delivery in a service so the API stays easier to test, maintain, and extend.

Sending an email is an external operation. SMTP credentials can be wrong, the mail provider can reject the message, the network can fail, or the request can time out. A common mistake is assuming that if the frontend submitted the form, the message was delivered. The API should distinguish between successful delivery, validation failure, rate limiting, and temporary mail service failure.

The frontend experience depends on this. Users should see a success message only after the backend confirms that the message was accepted for sending. If sending fails, the frontend should show a helpful error and keep the form data so the user can retry. If the API supports auto-reply emails, it should still be careful: an auto-reply should not hide a failure to notify the site owner.

For a beginner project, you do not need enterprise-level queues, but you should handle common failures clearly. Add structured errors, log unexpected mail failures on the server, and return a safe message to the client without exposing SMTP details.

Problematic handling:

          await transporter.sendMail(mailOptions);

          response.json({
            message: "Message sent"
          });

This assumes delivery always succeeds and does not provide a safe fallback if the mail provider fails.

Better delivery result:

          type EmailDeliveryResult =
            | { status: "sent"; messageId: string }
            | { status: "failed"; reason: string };

          async function deliverContactEmail(input: ContactMessage): Promise<EmailDeliveryResult> {
            try {
              const result = await transporter.sendMail(createOwnerEmail(input));

              return {
                status: "sent",
                messageId: result.messageId
              };
            } catch (error) {
              logger.error("Contact email delivery failed", {
                error
              });

              return {
                status: "failed",
                reason: "EMAIL_DELIVERY_FAILED"
              };
            }
          }

Route response:

          const delivery = await deliverContactEmail(validation.value);

          if (delivery.status === "failed") {
            return response.status(502).json({
              error: {
                code: "EMAIL_DELIVERY_FAILED",
                message: "Your message could not be sent right now. Please try again later.",
                status: 502
              }
            });
          }

          response.json({
            data: {
              message: "Your message has been sent successfully."
            }
          });

Optional auto-reply after owner email succeeds:

          async function sendAutoReply(input: ContactMessage) {
            await transporter.sendMail({
              from: config.mailFrom,
              to: input.email,
              subject: "We received your message",
              text: `Hi ${input.name}, thank you for reaching out. We received your message and will reply soon.`
            });
          }

          if (delivery.status === "sent") {
            sendAutoReply(validation.value).catch((error) => {
              logger.warn("Auto-reply failed", {
                error
              });
            });
          }

Pay attention to: Email delivery can fail. Return honest frontend-friendly responses, log server-side failures, and only show success after the backend confirms the message was accepted for sending.