Contact form for Next.js websites

Yes — App Router is the recommended approach. Use a client component ("use client") with a fetch call, or use a server action that posts FormData to the Splitforms endpoint. Both patterns are documented above.

Yes. The same React component with useState + fetch works identically in pages/contact.tsx. No App Router-specific features required.

Either works. Public env var is simpler and is fine if you've locked the key to your domain in the Splitforms dashboard (Settings → Security → Allowed domains). Keep it server-side via server action if you want maximum opacity — but a leaked-but-domain-locked key is functionally inert anyway.

Yes if you use the server-action pattern, or a plain HTML form action pointing at /api/submit with the thank-you redirect configured in the splitforms dashboard. The fetch-based variant requires JS.

Use a FormData submit path and do not set the Content-Type header yourself. Add enctype="multipart/form-data" for native form submissions or build new FormData(form) in a client component/server action. File uploads require the Storage integration and currently support 5 files per submission at 5 MB each.

Splitforms is API-only — there's no client library to install, just fetch. Your TypeScript code is type-safe naturally. The /api/submit endpoint returns { success: boolean, message?: string } which you can type yourself.

Yes to both. The client-component approach posts from the browser, so it works under output: "export", the App Router, and the Pages Router. The Server Action approach needs a server runtime (Vercel, a Node host) since actions run on the server.

Inlining access_key in a "use client" component makes the key visible to anyone who views source. That's fine if you've enabled allowed-domains in your Splitforms dashboard (Settings → Security) — anyone copying the key from your bundle can't use it from a different origin. If you haven't, use a server action so the key stays on the server.

If you submit to a server action via <form action={myAction}>, Next handles the FormData serialization for you. If you call the action manually with fetch, you have to set the right Content-Type and stringify yourself. Pick one path and stick with it — mixing causes 'Server Action invalid' errors.

If your form reads ?next=/something to support post-submit redirects, useSearchParams forces the page out of static generation. Either wrap the inner component in a <Suspense fallback={<Skeleton/>}> so the wrapper still prerenders, or accept dynamic rendering for the form route only.

If your route handler uses export const runtime = 'edge' and the form posts as multipart (file inputs), it'll silently miss fields. Use application/x-www-form-urlencoded or remove the edge runtime declaration.

React 19 strict mode will warn about onSubmit handlers in server components. Either lift the form into a client component, or use a pure HTML form with a server action and no JS.

If your server action ends with revalidatePath('/contact') to refresh some cached data, Next refetches the route segment and replaces the rendered tree — your client-side status === 'ok' state survives the action call but the surrounding layout re-renders, often closing modals or re-mounting wrappers. Either skip revalidatePath when the contact page itself doesn't need it, or use revalidateTag scoped to the specific data you actually changed (a CRM cache, not the page route). useFormStatus + a tag-based revalidate is the clean combo.

Without splitforms, you'd write a route handler at app/api/contact/route.ts, parse the FormData, configure SMTP via nodemailer or Resend (~10 minutes of secrets wrangling), add a Postgres or SQLite store for submissions, and then bolt on rate limiting, a honeypot check, an email-classifier or reCAPTCHA, and webhook fan-out. Server actions made the wiring slightly tidier in Next 14+, but the operational cost stays the same: a function with a runtime, a database, an outbound email provider, an inbox to monitor, and your name on the spam-filter incident report. Splitforms collapses all of that into a POST to a single URL.

On Vercel, the form works on every plan tier — server actions and client components both run inside the same edge/serverless function. Don't put the splitforms fetch inside a Vercel cron or background function (it's user-facing, latency matters). On Netlify with the Next runtime, server actions need the latest @netlify/plugin-nextjs (≥5.6). For self-hosted / Docker: configure output: 'standalone' in next.config.ts and pass SPLITFORMS_KEY as a runtime env var — never bake it into the image. For static export (output: 'export'), use the client-component path only — server actions aren't supported in static mode.