Server Actions or an API route for a Next.js landing page form?

A landing page form has one job: get a lead somewhere, without ever failing in the visitor's face right after they click "Submit". On Next.js, that job used to run through almost the same plumbing every time: a client component that intercepts submit, calls fetch() against an API route, waits for a JSON response, then updates the UI by hand. Since Next.js 13 and the App Router, another option exists: the Server Action, a function that runs server-side but that the form can call directly through its action attribute, with no intermediate route to write. Both approaches remain valid across LanderKit templates — the question isn't which one is "better" in the abstract, but which matches the level of resilience, security and simplicity your page actually needs.

What a Server Action actually changes

A Server Action is a function marked "use server", defined in a server file or at the top of a function, that Next.js automatically exposes as a secure network entry point. The form itself no longer needs JavaScript to work at all: its action attribute points straight at the function, the browser posts the data natively, and React only enhances the experience on top — a loading state through useFormStatus, error display through useFormState — without ever making the form's basic submission depend on the script. That's the same logic our complete guide to the landing page form has always recommended for resilience — except before Server Actions, getting it on Next.js meant writing your own <form method="POST"> fallback alongside the JavaScript flow.

What an API route still does better

A plain API route (app/api/lead/route.ts) stays an ordinary HTTP endpoint — documentable, testable with any REST client, and callable from another domain: an external CRM that wants to reuse the same endpoint, an end-to-end test that posts directly without rendering the page, or a future need to expose the same processing to a mobile app. A Server Action, by contrast, is meant to be called from the React render that declares it: it has no stable, documented URL, doesn't invoke cleanly from an external tool, and makes reuse harder if the same lead-processing logic ever needs to serve two very different forms in the codebase. For an integration that needs to stay reachable from the outside — the typical case of a webhook relayed to a CRM or Zapier — the API route keeps the edge on readability and portability.

Security: the difference isn't where you'd expect

One argument comes up often in favor of Server Actions: CSRF protection (cross-site request forgery) is supposedly automatic, while a plain API route would need it coded by hand. That's true of Next.js's implementation, which automatically checks the request's origin before running a Server Action — a genuine simplicity win. But that doesn't make an API route inherently vulnerable: Adam Barth, Collin Jackson and John C. Mitchell, in "Robust Defenses for Cross-Site Request Forgery," published in 2008 in the proceedings of the 15th ACM Conference on Computer and Communications Security (CCS 2008) (see on Google Scholar), show that reliable CSRF defenses rest on checking the request's origin or referer — exactly the mechanism an API route can implement itself, with a bit more code. The real difference, then, isn't "secure" versus "insecure", it's "protected by default without thinking about it" versus "protected if you take care to implement it". On an unauthenticated lead-capture form, CSRF risk is limited anyway — the real stakes sit more on the side of validating incoming data and blocking spam, as covered in our article on CAPTCHA.

Latency and hosting: what actually matters

On pure performance, both Server Actions and API routes run as serverless or edge functions depending on the deployment configuration, with a comparable cold-start cost either way — the difference between the two has nothing to do with latency. Liang Wang, Mengyuan Li, Yinqian Zhang, Thomas Ristenpart and Michael M. Swift, in "Peeking Behind the Curtains of Serverless Platforms," published in 2018 in the proceedings of USENIX ATC (see on Google Scholar), measured more than 50,000 function invocations across AWS Lambda, Azure Functions and Google Cloud Functions and show that cold-start delay — sometimes several hundred milliseconds — depends mainly on the runtime, the code package's size and how often the function is called, not on the invocation mechanism used to reach it. In practice, for a landing page hosted on Vercel: keeping the lead-processing function lightweight (no heavy dependency pulled in just to send an email) weighs more on response time than the choice between a Server Action and an API route.

The real edge of Server Actions: resilience for free

Where Server Actions clearly win is default resilience. A form wired to a Server Action still works if JavaScript hasn't finished loading, fails to load on a flaky connection, or runs in a context where the script gets blocked — the browser posts the form natively, the server function runs, the page reloads with the result. With an API route called through fetch() from an onSubmit handler, that safety net only exists if someone bothers to write it — a fallback <form action="/api/lead" method="POST">, which few teams add once the JavaScript flow is in place and tested. The UK's Government Digital Service has documented that on its own high-traffic sites, JavaScript fails to reach the browser properly on roughly 1.1% of visits — not because the user disabled it (only about 0.2% of cases), but because a script fails to load, a connection drops before the download finishes, or a mobile browser turns it off itself to save bandwidth. On a landing page where every conversion counts, a Server Action closes that leak with no extra code.

Comparison: Server Action or API route

How to choose for your landing page

1. A simple capture form (name, email, one or two fields) that only ever needs to be called from that one page: a Server Action is the most direct choice, with no-JavaScript resilience thrown in.
2. A form whose processing needs to be reused elsewhere — several templates sharing the same endpoint, an end-to-end test that posts directly over HTTP, or a future need to expose the same processing to another app: the API route keeps the edge.
3. A multi-step form with real-time validation and complex client-side conditional logic: both approaches coexist fine, with a Server Action handling only the final submission if you want.
4. An integration already designed as a webhook to a third-party tool (CRM, Airtable, an email platform): keeping a dedicated API route, documented and testable independently of the page's render, keeps maintenance simpler across several hands.
5. When in doubt, on a template shipped to production: a Server Action covers most simple lead-capture cases and shrinks the code surface to maintain, while staying compatible with a later move to an API route if the need grows.

Neither choice is a bad technical bet: both process the request server-side, out of the browser's reach, and both can be just as resilient as the other as long as someone writes the fallback an API route doesn't get by default. The difference comes down to the effort needed to get that resilience — none with a Server Action, coded by hand with an API route — and to how portable the processing is outside a React render. Every LanderKit template ships with its form already wired up and built for that resilience, whether on the Training/CPF template (demo) or the SaaS & Waitlist template (demo), at €89 each or €229 for the full ten-template pack. The technical call between a Server Action and an API route stays a question of architecture to settle once you wire in your own CRM or business logic, not a blocker to launching.