how to use v0 api

What the v0 API actually gives you

The v0 API turns a plain-language request into a running full-stack app, not just a code suggestion. It handles code generation, runs the result in a Vercel Sandbox, gives you a secure live preview, and provides a direct path to a Vercel deployment.

Think of each v0 chat as a private workshop for one app. The chat ID is the key to that workshop. v0 can read, edit, and run the files inside it, while every follow-up message continues from the current state. If your first message asks for an issue-triage dashboard and the next asks for an assignee column, the second request edits the app already on the workbench.

That stateful loop is the important part. A normal code model hands you text and leaves the execution to you. v0 starts the development server, checks the running code, and can catch and fix errors while it works.

The new v2 API is organized around four things you can reason about without learning its internals:

• Chats hold the app's current files, metadata, privacy, and Vercel project link.
• Messages are instructions and history. Their ordered parts can show text, thinking, file reads, file edits, searches, shell commands, tool calls, and agent actions.
• Previews are running builds protected by a short-lived token.
• Deployments ship the current chat state to Vercel.

This is also why old examples can mislead you. The current v2 quickstart imports from the v0 package. Older v1 examples import from v0-sdk, and v1 chat IDs do not work in v2.

How to use the v0 API

The shortest safe path is a small server route between your interface and v0. Your browser sends the user's prompt to your server. Your server holds the API key, calls v0, stores the returned chat ID, and sends only the result your interface needs.

1. Pick the right entry point

Use one of these three paths:

1. Start a complete app-generation interface with npx create-v0-sdk-app.
2. Add the server SDK to an existing product with npm install v0.
3. Give an existing agent access through the remote v0 MCP server, which uses OAuth instead of putting an API key in the MCP configuration.

The starter is the fastest way to see the whole pattern. It includes a React chat interface, server proxy routes, generated file views, an isolated preview app, and a v0 agent skill.

2. Create the key and keep it on the server

Create an API key in v0 settings and store it as V0_API_KEY in the server environment. Do not expose it in browser code and do not prefix it with NEXT_PUBLIC_.

Your local wrapper can run with npm run dev, but its server routes still call the hosted v0 API. This is a local integration, not a local copy of the v0 app-building system.

3. Create one chat for one app

The first call starts both a conversation and an app workspace:

import { v0 } from 'v0'

const created = await v0.chats.create({
  message: 'Build an issue triage app for a support team.',
})

if (created.error) throw new Error(created.error.message)
const chatId = created.data.chat.id

const changed = await v0.messages.send({
  chatId,
  message: 'Add a priority filter and an assignee column.',
})

if (changed.error) throw new Error(changed.error.message)

Persist chatId beside your own customer, workspace, or job record. Metadata can also group chats by those same identifiers, but metadata is for organization, not access control.

You do not have to start from an empty prompt. A chat can begin from a GitHub repository, a ZIP archive, or a set of files.

4. Choose how the work returns

Use a synchronous call when the caller can wait for the finished result. Use an asynchronous call for scripts, webhooks, and CI jobs that should queue work and check later. Use streaming when a person is watching and your interface should show the agent reading files, editing code, running commands, and reporting progress.

Chat and message responses include usage, so you can record token counts and credit cost when each job finishes.

5. Proxy the preview, do not expose it directly

The API returns a preview URL and a short-lived token. A browser iframe cannot safely attach that token itself, so the documented design sends iframe requests through a backend proxy you control.

Put that proxy on a preview-only site with a different registrable domain from your main application. Generated previews can execute untrusted code. Your proxy must also authenticate the current user and verify that the user may access the requested chat. The v0 preview helper does not do that authorization for you.

6. Deploy only after your own checks

When the app is ready, v0.chats.deploy({ chatId }) deploys the current chat state to Vercel. Environment variables belong to the attached Vercel project and are managed through the Vercel API, so database credentials and third-party keys need a separate, deliberate setup step.

What it costs

v0 charges through credits rather than a flat price per generated app. Input tokens include the prompt, uploaded content, chat history, source files, and other context v0 reads. Output tokens are what the agent generates. Long-running chats can therefore cost more as their history and codebase grow.

The Free plan is $0 per month with $5 in monthly credits and a seven-message daily limit. Plus is $30 per user per month and Business is $100 per user per month; both include $30 in monthly credits per user. When the available credits are used, generation pauses.

For a customer-facing product, log the usage returned by every chat and message call. Give each tenant a budget, a job limit, or both. Otherwise one unusually large repository or an endless revision loop can consume the shared balance.

Seven use cases, ranked by who gains most

The best uses put v0 inside an existing workflow where the product already knows the user, the data, and the kind of app that should be built.

If you are deciding whether v0 is the underlying engine or the whole product you need, compare it with the best AI app builders in 2026. The distinction matters: an API is useful when you want to own the customer experience, rules, billing, and review flow.

Three products worth building

There is real demand here, but the generic app-builder market is already crowded. The opportunity is not another empty prompt box. It is a builder that knows one valuable job unusually well.

1. Best bet: a vertical app builder inside an existing SaaS

Build a constrained generator for one profession, sold as an add-on to software those customers already use. A property-management platform could generate owner portals. A logistics platform could generate shipment exception dashboards. A franchising platform could generate location launch trackers.

The demand is broad enough to support the category. ai app builder gets about 12,100 US Google searches a month and the dataset reports 50% yearly growth. People ask AI assistants to build an app with ai about 392 times a month, up from 231 in August 2025, roughly 70% growth. Existing app builders already charge from $16 to $160 per month, which shows that buyers accept a recurring software price for this job.

The smallest sellable version needs two or three approved app types, a structured intake form, one v0 chat per customer app, a streamed review screen, a secure preview proxy, and a human-controlled deploy button. The moat is the host product's data model, permissions, templates, and distribution.

The catch is brutal but useful: a generic wrapper has almost no defense. If the product cannot say what it knows about the customer's work that v0 alone does not know, do not build it.

2. A white-label website and campaign builder for agencies

Give an agency a branded client intake, a fixed set of page types, its own design-system skill, a revision queue, and a deploy handoff. Clients see the agency's experience, while v0 handles the app workspace and live preview behind it.

ai website builder gets about 40,500 US Google searches a month, with 49% yearly growth in the keyword dataset. That is the biggest visible pool in this research, and it also means the market is full of capable incumbents. The useful wedge is not “make any website.” It is “make this agency's kind of site, with this stack, these components, and this approval process.”

An MVP needs one brand configuration, three page patterns, asset upload, preview comments, and deployment approval. The catch is support: clients will judge the agency, not v0, when generated copy, layout, accessibility, or integrations need correction.

3. A feature-request-to-preview bot for product teams

Turn an approved issue into a running candidate change. A GitHub App or internal webhook imports the repository, starts an asynchronous v0 chat, records the chat ID, and posts the preview back to the ticket. A person reviews it before any merge or deployment.

Google records about 390 monthly US searches for how to build an app with ai, and the dataset reports 86% yearly growth. AI-assistant demand for build an app with ai reached 392 monthly prompts in July 2026. That supports interest in whole working applications, although it does not prove a standalone CI market. Treat this as a team feature or a developer-platform add-on, not a broad self-serve bet.

The MVP is a webhook, repository allowlist, async job runner, v0 chat store, isolated preview, and approval status. The catch is risk. Generated preview code is untrusted, repository access is sensitive, and a plausible demo is not evidence that tests, security, migrations, and edge cases are correct. Never make production deployment the default action.

For a wider view of where this sits among coding agents and prompt-to-app tools, see the best vibe coding tools in 2026.

What the v0 API does not solve

The API supplies an app-building worker and its workshop. You still own the product around it.

• It does not decide what should be built. A vague request can still produce a polished version of the wrong thing. Your intake, templates, constraints, and review gates matter.
• It does not authorize your customers. The preview helper forwards preview traffic, but your application must decide who may access each chat.
• It does not make generated code trusted. Serve previews from a preview-only site on a different registrable domain, and review code before it reaches production.
• It does not carry v1 chats into v2. Choose a v1 version, download it as a ZIP, and create a new v2 chat from that state.
• It does not replace the Vercel API. Environment variables and several project operations live on the attached Vercel project.
• It does not make cost fixed. Source files, conversation history, prompts, and output all contribute to token usage.
• It is not a local app-building engine. You can run your integration locally, but the documented workflow calls v0's hosted API and runs previews in Vercel infrastructure.

My take: use v0 when the running preview and stateful iteration are the product advantage. If you only need a code snippet, a one-off component, or a tightly deterministic file transform, the extra workspace, proxy, credit accounting, and deployment machinery are unnecessary.

If you want a v0-powered builder designed and hardened for your business, I build production AI systems.