What is a serverless function, and why did Vercel add api/?

What it actually is

A serverless function is backend code you deploy without renting or maintaining a server yourself. You write the code, hand it to a platform like Vercel, Netlify, or Supabase, and the platform starts a fresh instance to run it only when a request comes in, then can shut that instance down again. You never patch an operating system or restart a crashed process; the platform owns the machine, you own the function.

Think of it like calling a locksmith instead of keeping one on staff. A regular server is an employee on the clock all day whether or not anyone needs them, and you pay for every hour regardless of how much work happens. A serverless function is a contractor you call for one job: they show up, do the work, and leave, and you’re billed only for the minutes they worked. There’s a real machine underneath somewhere, you just never manage it. You rent seconds of compute, not the machine itself.

Why your AI just did this

Your agent reaches for a serverless function the moment your app needs to talk to something it shouldn’t expose in the browser. Any paid or private API, OpenAI, Stripe, Resend, a weather API with a rate-limited key, needs its key kept off the client, because anyone can open dev tools and read every line of JavaScript your app ships. So instead of calling that API directly from your frontend, your agent writes a small handler, drops it in an api/ folder, and points your frontend at that instead. The handler reads the real key from an environment variable and attaches it server-side, where only your own function sees it.

This is also a naming convention agents default to. Vercel, and frameworks like Next.js built on top of it, turn any file inside api/ (or app/api/) into a live API endpoint automatically, no routing config, no separate backend to stand up. Drop api/send-email.ts in your project, deploy, and /api/send-email exists. That’s why a request like “add a contact form that emails me” produces a brand new file you never asked for by name.

When you’ll run into it

The first sighting is usually a folder you didn’t create: api/ sitting next to your frontend code, holding one file per endpoint, each exporting a handler that takes a request and returns a response.

Cold starts show up as an odd delay: the first request after your app has been quiet for a while takes noticeably longer, because the platform has to start a fresh instance before it can run your code. The next few requests are fast, because that instance stays warm and gets reused.

Timeouts show up when a function runs too long, waiting on a slow AI response, a large file, or a stuck database query. Vercel returns a 504 and names the failure FUNCTION_INVOCATION_TIMEOUT in its error page and logs. A payload that’s too big for one request produces a different error, FUNCTION_PAYLOAD_TOO_LARGE. Both point at the same problem: the job doesn’t fit the shape of a function.

Long-lived connections cause a subtler symptom: a chat or live feature that works, then drops silently. Serverless functions are built to run, answer, and stop, and holding a WebSocket open indefinitely works against that design. As of July 2026, Vercel’s own functions can serve WebSocket connections directly, but that connection still closes the moment the function hits its own duration limit, and a reconnecting client can land on a different instance. That’s why real-time apps often lean on a dedicated realtime service instead of asking a plain function to hold the line open.

What to check

• Open your project’s api/ folder before asking for changes; each file there is a separate live endpoint with its own URL
• Confirm any key or secret used inside those files comes from an environment variable, never typed directly into the code or into anything your frontend can reach
• If a request is slow once and fast right after, that’s a cold start, not a bug; ask whether it matters for what you’re building (a login screen notices it, a background export usually doesn’t)
• If you see FUNCTION_INVOCATION_TIMEOUT, ask whether the task belongs in a function at all; long jobs like video processing usually need a background worker or a queue instead
• For anything that needs to stay connected (chat, live cursors, notifications), ask specifically how reconnects are handled, since the connection eventually drops no matter which hosting platform you’re on
• Check your plan’s stated limits for memory and duration before designing around a long task; free tiers are generous now but still capped, and the numbers differ by provider

Say it like a dev

Instead of: “why did my project suddenly have this weird api folder” Say: “Explain what this file in api/ does and why it’s a serverless function instead of code in my frontend.”

Instead of: “the live chat just stops working after a while” Say: “Is the chat dropping because the serverless function’s connection hit its timeout? How does the client reconnect?”

Instead of: “this endpoint is fast sometimes and slow other times, is it broken” Say: “Is the slow response a cold start? Should I worry about it for this feature, or is it expected on our plan?”