Contact form for Nuxt apps

Save the snippet above as pages/contact.vue. Add splitformsKey under runtimeConfig.public in nuxt.config.ts, populated from process.env.NUXT_PUBLIC_SPLITFORMS_KEY. Visit /contact — done. No /server/api route needed.

Yes — all three modes. The form is client-side (uses fetch in a setup-script handler), so it works regardless of the page's render mode. SSR and SSG just affect how the form's wrapper page is generated.

Use a status ref with four values: idle, loading, ok, err. Render error messages from the splitforms response inside v-if="status === 'err'". The fetch returns { success, message? } — use the message for user-facing errors.

Yes — see the alternative-pattern snippet. Define the key as private under runtimeConfig and proxy through server/api/contact.post.ts. Adds latency but keeps the key entirely server-side.

Two options. (1) Stay on-page with a Vue-rendered success message (default in our snippet). (2) After a successful fetch, call await navigateTo('/thanks'). For native form posts, configure the absolute thank-you URL in Dashboard → Form settings → Redirect.

Yes — all three. Nuxt UI's <UForm> component works (it's just a styled <form>); Nuxt Content can embed the contact form via MDC syntax; Nuxt Studio's editor previews the form correctly. Same backend regardless.

Nuxt's runtimeConfig has two scopes. Anything under runtimeConfig.public is exposed to the browser bundle; anything else is server-only. If you put splitformsKey directly in runtimeConfig (not .public), useRuntimeConfig().splitformsKey returns undefined client-side.

Calling useRuntimeConfig() inside a regular function (not inside <script setup> or a composable) returns {}. Always call it at the top of <script setup> and capture the value, then use config.public.splitformsKey inside event handlers.

If you proxy the splitforms call through a Nuxt server route (/server/api/contact.post.ts), the fetch round-trip eats your Cloudflare Worker CPU budget. On Cloudflare Pages Free tier, this can fail under load. Skip the proxy: have the form POST directly to splitforms.com.

If you embed the form in a Markdown file rendered by Nuxt Content, MDC syntax may interpret your inputs as MDC components. Wrap the form in <NuxtContent> (or use :component="ContactForm") instead of inline form HTML.

Nuxt's $fetch('/url', { body: formData }) automatically sets Content-Type: multipart/form-data AND tries to JSON-stringify your FormData. Use the native fetch() API in the form handler — $fetch is for typed Nitro routes, not third-party endpoints.

When you run nuxt generate for SSG, Nuxt's payload extractor serializes any reactive ref() values referenced during prerender into a __NUXT__ global on the static HTML — including the initial state of your form fields if they're populated server-side from useAsyncData. If you've prefilled a name ref from a logged-in user fixture, every visitor sees that fixture's value on first paint until hydration overrides it. Keep form refs initialized to empty strings on the server, or wrap the form in <ClientOnly> so SSG doesn't snapshot any default state at all.

Nuxt 3's Nitro server gives you /server/api/contact.post.ts for free — write a handler, parse FormData, send email, store the submission, fan out a webhook. The DX is good; the operational cost is the same as any framework: an SMTP integration (Nodemailer + a transactional provider), a Postgres or KV store for submissions, anti-spam logic (honeypot + classifier or hCaptcha), and webhook signing if you want secure delivery to Slack/Discord/Make.com. Each feature is another deploy artifact, another env var, another thing to monitor. Splitforms is the inverse: skip the /server/api route entirely (post directly from the page), or proxy through a one-line Nitro route to keep the key server-side.

Nuxt's Nitro server abstracts away deployment — pick a preset (vercel, netlify, cloudflare-pages, cloudflare-workers, node-server, static, aws-lambda, digital-ocean) and ship. The form's POST is cross-origin to splitforms, so the preset doesn't affect delivery. On Cloudflare Workers (10ms CPU on free tier), strongly prefer Pattern A — Pattern B's $fetch round-trip can blow the budget under load. Use runtimeConfig.public.splitformsKey (client-exposed) for Pattern A and runtimeConfig.splitformsKey (server-only) for Pattern B. Both populate from NUXT_PUBLIC_SPLITFORMS_KEY / NUXT_SPLITFORMS_KEY env vars.