Vercel's v0 API Turns App-Building Into a Tool Call

Vercel used to be the place you deployed an app after you built it.

As of this month, it's also the thing that builds the app. No dashboard required.

The v0 API went generally available in August, and it does a lot more than the old v0.dev chat window ever did.

Send it a prompt over HTTP, it generates a full application, boots it inside a Vercel Sandbox, and hands you back a live preview URL.

Send a follow-up message on the same chat ID, and it edits the app that already exists instead of starting over. Attach a Vercel project, hit the deploy endpoint, and the app is live on a real domain.

No human opened a browser tab at any point in that chain. That's not a bug in the demo. That's the pitch.

I spent a weekend wiring the v0 API into an n8n workflow to find out what "an agent builds your app" actually looks like once you take the demo video out of it.

What the v0 API Actually Ships

The core primitive is a chat, not a request-response call.

You create one, it holds the app's state, and every message after that is an edit against the same project.

const chat = await fetch("https://api.v0.dev/v1/chats", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.V0_API_KEY}` },
  body: JSON.stringify({
    message: "Build a waitlist page with an email form and Supabase insert",
  }),
});
const { id, demo } = await chat.json();
// demo is a live preview URL, already running

That chat ID is the whole interface. Send another message against id and v0 edits the existing app in place, the same way you'd send a second prompt in a coding session.

Except there's no editor open. No human reading the diff between messages.

That's the part that's different from every "AI app builder" that came before it. You're not exporting a zip and running npm install yourself.

The app is already deployed, on Vercel's infrastructure, before you've read a single line it wrote.

Streamed requests expose the agent's individual actions as it works: file reads, edits, searches, shell commands. That's a genuinely useful primitive if you're building your own tooling on top of the v0 API.

It's also the only thing standing between you and a deployed app you never actually looked at.

I Turned It Into an n8n Node

I already wrote about how n8n's AI Assistant changed what a workflow builder's job looks like. The v0 API is the same shift, one layer up the stack.

I built an n8n workflow that takes a client brief from a form submission, prompts the v0 API to scaffold a landing page, waits for the chat to finish, and posts the preview link to Slack.

Brief to reviewable link: about four minutes, most of it spent waiting on the sandbox to boot.

The equivalent by hand, scaffolding a Next.js project, wiring up a form, deploying it, used to eat half a day even with Claude Code doing the heavy lifting.

The catch showed up on the third test run. I gave it a brief for a pricing page with three tiers, and it shipped a working page with a Stripe checkout button on the wrong tier: the button on the $49 plan pointed at the $19 price ID.

Nothing threw an error. The page rendered fine. Someone would have paid the wrong amount before anyone noticed, because the deploy step doesn't check whether the thing it built matches what you asked for. It checks whether the thing it built runs.

This Isn't Happening in Isolation

Vercel isn't the only one racing to turn "AI builds an app" into a callable endpoint. Lovable, Bolt, and Replit's agent have all been pushing the same direction this year, chat interface in front, generated app out the back.

What's different about the v0 API is that Vercel already owned the other half of the loop.

Lovable and Bolt still hand you a generated app that needs somewhere to live. The v0 API skips that handoff entirely, because the company generating the code is the same company running the sandbox, the preview, and the production deploy.

That's a genuine advantage if you're building on top of it. It's also exactly why the lock-in point matters more here than it does with the other tools. A Lovable export is portable because it has to be. A v0 chat's deploy history isn't going anywhere without you rebuilding the pipeline that produced it.

The Uncomfortable Part

Here's the part of the launch post nobody's dwelling on: the v0 API ships to a real URL by default, and review is something you have to build back in yourself.

Every previous generation of "AI writes your app" tooling put a human between the generation and the deploy, if only because the export step forced you to look at the files before running them.

The v0 API collapses that gap on purpose. That's the entire pitch: agents building and shipping apps without humans in the loop.

Vercel says so in their own materials, not as a risk, as the feature.

For a hackathon prototype, that's fine. For anything with a payment flow, a form that writes to a database, or a page a client is going to see before you do, that's a liability with a working deploy URL attached to it.

The n8n AI Assistant at least puts wrong nodes in front of you on a canvas before anything runs.

The v0 API puts wrong code in front of a customer, on a live domain, and calls that success because the build passed.

I'm not saying don't use it. I'm saying the review step that used to be implicit, because you had to open the files to deploy them, is now something you have to explicitly wire back in. Most people wiring the v0 API into automations right now aren't doing that. I wasn't, on my first pass either.

Why Vercel Actually Wants This

Vercel's hosting margins are a mature business at this point.

The v0 API is a bet that the more interesting business is being the layer where the app gets generated in the first place, and hosting is just what happens to it afterward.

That's a real strategic move, not a feature bolt-on. Once the app-generation step lives on your infrastructure by default, switching hosts means rebuilding your generation pipeline, not just changing a DNS record.

I left Zapier for self-hosted n8n specifically to avoid that kind of lock-in on the automation side. The v0 API is Vercel doing the opposite: building the lock-in on purpose, and being upfront about it being the plan.

I don't think that's a villain move. It's the correct move if you're Vercel. Every chat message you send deepens the dependency, and the preview URL only resolves inside their sandbox until you explicitly export it.

But builders wiring the v0 API into client pipelines should know they're not just picking an app generator. They're picking a hosting relationship that gets harder to leave the further in you go.

What I'd Actually Wire Before I Trust This

I kept the workflow. I didn't keep it unattended.

The version running now stops after the v0 chat finishes and posts the preview link plus the streamed action log to Slack, instead of hitting the deploy endpoint automatically.

A human reads the diff of what actually got built, same as reading a pull request, before anything goes live on a domain a client will visit. The streamed file-edit log I mentioned earlier is what makes that fast. Without it, the review step would mean reading the whole generated codebase cold.

That costs me the four-minute end-to-end number I quoted earlier. It's closer to fifteen once someone actually reads it. I'll take the fifteen.

The pricing-tier bug cost nothing to catch at that stage. It would have cost real money to catch after a customer clicked the wrong button.

Wire the API in. Skip the auto-deploy step until you trust what it ships. Read the diff anyway.