How to Add a Form Backend to a v0 (Vercel) App (2026)

Why a v0 form has no backend

v0 by Vercel is a generative UI tool. You prompt it, and it returns polished React components — usually with Tailwind and shadcn/ui — that you can drop into a Next.js app. It is excellent at the interface. What it deliberately does not do is stand up server infrastructure. A v0 "contact form" is a client component: inputs, validation, a styled submit button, and an onSubmit that, out of the box, doesn't send anywhere real.

That's by design — v0 generates UI for developers who already have (or will build) the backend. The gap shows up the moment you ship: the form looks production-ready, someone fills it out, and the submission evaporates. There was never a server route to catch it.

You have two ways to close that gap. Write the backend yourself with a Next.js Route Handler or Server Action plus an email provider — appropriate when the form drives your app's own data. Or, for the common case of a contact / waitlist / lead form whose job is "capture it and tell me," point the form at a hosted backend and skip the server code entirely. This guide does the second; if you want the first, the trade-offs are in Server Actions vs form backends.

Step 1: Get a free splitforms access key (1 minute)

splitforms is the backend we'll point the v0 form at. Free tier: 500 submissions/month with dashboard storage and AI spam filtering; Starter adds email forwarding and webhooks — no credit card.

1. Go to splitforms.com/login, enter your email, paste the 6-digit code
2. Copy the access key (sf_live_...)
3. Set your notification email under Settings → Notifications

The key is a public identifier — safe in client code. You can hardcode it or, if you prefer, expose it as a NEXT_PUBLIC_SPLITFORMS_KEY environment variable in Vercel. Both are fine; it's not a secret.

Step 2: Point the v0 form's submit at splitforms

Keep every component v0 generated. Change only the submit handler. Here it is for a typical v0 + shadcn/ui form — drop it into the existing onSubmit:

"use client";

import { useState } from "react";

const ACCESS_KEY = process.env.NEXT_PUBLIC_SPLITFORMS_KEY ?? "YOUR_ACCESS_KEY";

export function ContactForm() {
  const [status, setStatus] = useState<"idle" | "sending" | "ok" | "error">("idle");

  async function onSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    setStatus("sending");

    const data = new FormData(e.currentTarget);
    data.append("access_key", ACCESS_KEY);

    try {
      const res = await fetch("https://splitforms.com/api/submit", {
        method: "POST",
        body: data,
      });
      if (!res.ok) throw new Error();
      setStatus("ok");
      e.currentTarget.reset();
    } catch {
      setStatus("error");
    }
  }

  return (
    <form onSubmit={onSubmit}>
      {/* keep v0's generated shadcn/ui inputs and styling as-is */}
      <input name="name" required />
      <input name="email" type="email" required />
      <textarea name="message" required />

      {/* honeypot */}
      <input name="botcheck" type="checkbox" tabIndex={-1}
             autoComplete="off" style={{ display: "none" }} />

      <button type="submit" disabled={status === "sending"}>
        {status === "sending" ? "Sending..." : "Submit"}
      </button>

      {status === "ok" && <p>Thanks — we got your message.</p>}
      {status === "error" && <p>Something went wrong. Try again.</p>}
    </form>
  );
}

That's the entire backend. No app/api/contact/route.ts, no email SDK, no environment plumbing beyond the optional public key. The three things that matter: append access_key to the FormData, keep a name on every input (these become the fields in your dashboard and Starter inbox emails), and keep the hidden botcheck honeypot.

If your v0 form uses react-hook-form (common with shadcn/ui), submit the validated values the same way — build a FormData or post JSON; splitforms accepts both multipart/form-data and application/x-www-form-urlencoded. The pattern is identical to sending form data with fetch.

Why this beats writing a Route Handler for a contact form

You can write app/api/contact/route.ts, validate the body, call Resend or Nodemailer, handle errors, and add spam protection. For a form that's genuinely part of your product, do that. For a contact or lead form, here's what the hosted route saves you:

• No email provider setup. No Resend account, API key, or domain verification — delivery is included with dedicated SMTP.
• No spam code. Honeypot plus an AI classifier run server-side; you don't build or maintain them.
• No cold-start or CORS debugging. The browser posts straight to a stable endpoint; nothing to deploy or warm up.
• A dashboard for free. Search, filter, and export submissions without building an admin UI or querying a table.

The submission still lands as structured data you can pipe anywhere — including back into your own database via a webhook to a Vercel Route Handler if you want a copy. You get the convenience of the hosted backend without giving up control of the data.

Step 3: Test in preview and ship

Submit a test entry from v0's preview or local dev. Within ~5 seconds you should get a notification email and see the submission in your splitforms dashboard. Because the post goes directly to splitforms, it behaves the same in preview and in production — no "works locally, breaks on Vercel" surprises.

Before launch, open the splitforms security tab and add your Vercel production domain (and any custom domain) to Allowed Domains. If something doesn't arrive, check the dashboard first — present-but-no-email means a forwarding issue; absent means the POST didn't reach splitforms (verify the URL and access key in the console). Full checklist: contact form not working.

What to do next

• Building with Lovable instead? Add a contact form to a Lovable app.
• Native Next.js path: Next.js 15 Server Actions vs a hosted form backend.
• Pick a backend: top 10 Next.js form backends and splitforms vs Forminit.
• Drive forms from an AI agent: splitforms MCP server. Ready to wire it: get a free key.

FAQ