Today we're introducing the new v0 API: programmatic, headless access to v0's app-building agent. Send a prompt and v0 generates an app, starts a dev server in a Vercel Sandbox, and gives you a preview URL you can embed in your own UI.
Each chat is an isolated workspace for one app, where v0 can read, edit, and run the files. Follow-up messages continue from the current state. v0 verifies the code running in the sandbox, so it can catch and fix errors in your app in real time.
The new API is now available in public beta.
Create a chat from a prompt, stream its work, and render the live preview, all from your own interface. First, install the v0 SDK.
Then, create a chat. Send a prompt, and v0 generates your app.
Send follow-up messages to the same chat to keep building. Each one continues from the current state.
Then embed the app.
A prompt goes in, a running app comes out. v0 operates the sandbox, dev server, and preview behind it. When you're ready, deploy to Vercel in one API call. v0 manages whole pipeline.
The new API lets you run v0's app builder inside your own product or pipeline. This opens use cases like:
Below, we break down the API primitives behind this workflow.
Each chat holds one app's state, and a repo or Vercel project can have many chats. Store each chat's ID and send that follow-up messages using that ID. Chat metadata lets you group chats by customer, workspace, app, or any key your product already uses.
Learn more about messages.
Your interface needs to show what happens between sending a request and seeing the updated preview.
Every message includes ordered
Usage is returned with chat and message responses, so you can account for the work when it finishes.
Chat creation and messages support synchronous, asynchronous, and streaming responses. Use sync when the caller needs the completed response. Use async to queue the work and receive updates via webhook or poll for v0's response later. Stream the request to render v0's work as it happens.
You can also create a chat from a repository, ZIP archive, or set of files.
Each chat gets a short-lived preview token. Fetch it from a server route and proxy browser requests through it, so your v0 API key never reaches the browser. When a preview is ready, traffic forwards to it; while the Sandbox spins up, requests fall back to a loading route. Point an iframe at your proxy route and cache the preview details until they expire.
Read more about Accessing Previews in the docs.
Turn on specific MCP servers for a chat, or use the defaults.
Design Systems 2.0 saves a design system as a skill. Include it in a request to load its components, tokens, setup, and starter app.
You can pass up to three per request, from team or user memory, skills.sh, or the connected repo, or let the agent pull in your team's skills on its own.
If you're building an agent, give it v0 as a tool. When a task needs a real app instead of a text answer or code, the agent calls v0 to create or continue a chat, resolve any questions or approvals, and get back a running preview or deployment. v0 handles the code and runtime inside the Sandbox; your agent keeps control of its workflow and final response.
There are three ways to connect it:
Connect the v0 MCP server to an IDE, desktop assistant, or agent runtime that supports MCP.
The first connection starts an OAuth flow. The MCP server exposes tools for creating chats, listing chats, getting chat details, listing and sending messages, resolving pending tasks, and getting preview URLs.
For TypeScript agents built with AI SDK, use
The agent decides when to create or continue a chat. Your AI SDK run keeps control of the orchestration and final response.
For eve agents, add an OpenAPI connection file. eve turns the allowed operations into tools and attaches the API key at execution time, out of model context.
Create a Vercel project for the chat, then manage its environment variables, integrations, and settings through the Vercel API. Your apps include enterprise-grade security and observability tooling out of the box.
When you're ready to ship, deploy the chat to Vercel.
Chats from the previous version of the v0 API don’t run on the new one, so carry them forward. Pick the version you want to keep, download it as a ZIP, and create a new chat from that ZIP. Store the old identifiers in the new chat’s metadata if you need traceability.
The migration guide covers the full mapping. The main changes:
Create an API key in v0 settings and install the SDK.
Or, scaffold a full app.
Read the documentation and migration guide.
Read more
Continue reading...
Each chat is an isolated workspace for one app, where v0 can read, edit, and run the files. Follow-up messages continue from the current state. v0 verifies the code running in the sandbox, so it can catch and fix errors in your app in real time.
The new API is now available in public beta.
How it works
Create a chat from a prompt, stream its work, and render the live preview, all from your own interface. First, install the v0 SDK.
Then, create a chat. Send a prompt, and v0 generates your app.
Send follow-up messages to the same chat to keep building. Each one continues from the current state.
Then embed the app.
A prompt goes in, a running app comes out. v0 operates the sandbox, dev server, and preview behind it. When you're ready, deploy to Vercel in one API call. v0 manages whole pipeline.
What this unlocks
The new API lets you run v0's app builder inside your own product or pipeline. This opens use cases like:
A white-labeled app builder: Your users describe an app and get a working one back, inside your product.
Automated app changes: Trigger v0 from a script, CI job, or webhook to generate a new app or update an existing one.
A build tool for your agents: An agent hands back a working app instead of a code snippet.
Below, we break down the API primitives behind this workflow.
Start with a chat
Each chat holds one app's state, and a repo or Vercel project can have many chats. Store each chat's ID and send that follow-up messages using that ID. Chat metadata lets you group chats by customer, workspace, app, or any key your product already uses.
Learn more about messages.
Stream the trace
Your interface needs to show what happens between sending a request and seeing the updated preview.
Every message includes ordered
parts: text, thinking, file reads and edits, searches, bash commands, tool calls, and agent actions. The same object can drive a one-line status, a changed-files view, or the full trace.Usage is returned with chat and message responses, so you can account for the work when it finishes.
Choose sync, async, or streaming
Chat creation and messages support synchronous, asynchronous, and streaming responses. Use sync when the caller needs the completed response. Use async to queue the work and receive updates via webhook or poll for v0's response later. Stream the request to render v0's work as it happens.
Work from existing code
You can also create a chat from a repository, ZIP archive, or set of files.
Render the dev server preview
Each chat gets a short-lived preview token. Fetch it from a server route and proxy browser requests through it, so your v0 API key never reaches the browser. When a preview is ready, traffic forwards to it; while the Sandbox spins up, requests fall back to a loading route. Point an iframe at your proxy route and cache the preview details until they expire.
Read more about Accessing Previews in the docs.
Bring your own tools and design systems
Turn on specific MCP servers for a chat, or use the defaults.
Design Systems 2.0 saves a design system as a skill. Include it in a request to load its components, tokens, setup, and starter app.
You can pass up to three per request, from team or user memory, skills.sh, or the connected repo, or let the agent pull in your team's skills on its own.
Use v0 from agents
If you're building an agent, give it v0 as a tool. When a task needs a real app instead of a text answer or code, the agent calls v0 to create or continue a chat, resolve any questions or approvals, and get back a running preview or deployment. v0 handles the code and runtime inside the Sandbox; your agent keeps control of its workflow and final response.
There are three ways to connect it:
MCP
Connect the v0 MCP server to an IDE, desktop assistant, or agent runtime that supports MCP.
The first connection starts an OAuth flow. The MCP server exposes tools for creating chats, listing chats, getting chat details, listing and sending messages, resolving pending tasks, and getting preview URLs.
AI SDK
For TypeScript agents built with AI SDK, use
@v0-sdk/ai-tools to expose v0's API operations as tools in the agent's own loop.The agent decides when to create or continue a chat. Your AI SDK run keeps control of the orchestration and final response.
eve
For eve agents, add an OpenAPI connection file. eve turns the allowed operations into tools and attaches the API key at execution time, out of model context.
Connect a Vercel project
Create a Vercel project for the chat, then manage its environment variables, integrations, and settings through the Vercel API. Your apps include enterprise-grade security and observability tooling out of the box.
When you're ready to ship, deploy the chat to Vercel.
Migrate your chats
Chats from the previous version of the v0 API don’t run on the new one, so carry them forward. Pick the version you want to keep, download it as a ZIP, and create a new chat from that ZIP. Store the old identifiers in the new chat’s metadata if you need traceability.
The migration guide covers the full mapping. The main changes:
Usehttps://api.v0.dev/v2for new requests.
The chat holds current app state and message hold its history.
Replace version workflows with chat file workflows, and v0 Project organization with chat metadata.
UsevercelProjectIdplus the Vercel API for project operations.
Render messageparts, not only final text.
Get started
Create an API key in v0 settings and install the SDK.
Or, scaffold a full app.
Read the documentation and migration guide.
Read more
Continue reading...