The v0 API Is GA: Vercel Just Made Its App-Building Agent a Headless Service

On August 5, Vercel made the v0 API generally available: programmatic, headless access to the agent behind v0.app. Send a prompt, and v0 generates an app, starts a dev server in a Vercel Sandbox, and hands you a preview URL you can embed in your own UI. One API call goes from prompt to a running application, and a second call deploys it.

The announcement, dated August 5, is short on positioning and long on mechanics, which is appropriate: the interesting part is not that an API exists, it is what the API models. This is not a "generate a code snippet" endpoint. It is a stateful agent that reads, edits, and runs files in an isolated workspace, streams its trace back to you, and verifies its own work against a running dev server.

What shipped#

The new surface is a v2 API (https://api.v0.dev/v2) plus an SDK in the v0 npm package:

• Chats hold app state. Each chat is one app in one workspace. Follow-up messages continue from the current state, so iteration is a conversation, not a pile of one-shot generations.
• Messages return ordered parts. Text, thinking, file reads and edits, searches, bash commands, tool calls, agent actions. The same parts array can drive a one-line status spinner, a changed-files list, or a full trace UI.
• Sync, async, and streaming modes. chats.create blocks for the completed response, createAsync queues work and returns IDs for polling or webhooks, and createStream emits the agent's work as it happens. Usage is returned with chat and message responses so you can meter the work.
• Work from existing code. chats.createFromRepo accepts a GitHub repository URL and branch, a ZIP archive, or a set of files.
• Secure previews. Each chat gets a short-lived preview token. The pattern Vercel recommends is fetching it from a server route and proxying browser requests, so your API key never reaches the client. An iframe points at your proxy; requests fall back to a loading route while the Sandbox spins up.
• Deploy in one call. chats.createVercelProject wires the chat to a Vercel project, and chats.deploy ships it. Environment variables, integrations, and settings then run through the normal Vercel API.

The agent-native part#

The v0 API was clearly designed to be called by other agents, not just by humans in a UI:

• MCP server. Point any MCP-capable client at https://v0.app/api/mcp; the first connection starts an OAuth flow. Exposed tools cover creating chats, listing chats, sending messages, resolving pending tasks, and getting preview URLs.
• AI SDK tools. The @v0-sdk/ai-tools package turns v0's API operations into tools for TypeScript agents built with the AI SDK, letting the agent decide when to create or continue a chat inside its own orchestration loop.
• eve connections. For Vercel's eve agents, an OpenAPI connection file turns allowed operations into tools, with the API key attached at execution time, out of model context.
• Skills and design systems. You can pass up to three skills per request, from team or user memory, skills.sh, or the connected repo. Design Systems 2.0 saves a design system as a skill that loads its components, tokens, and starter app, which is the first real mechanism for keeping generated apps on your design language at scale.

There is a v1-to-v2 migration guide for existing users, and the breaking changes are honest about the new model: v1 chats do not run on v2, the chat now holds app state while messages hold history, version workflows become chat file workflows, and clients must render message parts rather than only final text.

Why it matters#

Vercel has been assembling an agent platform for a year: eve for agents, Sandbox for isolated runtimes, AI Gateway for model routing, and now a headless v0. The pattern across all of them is the same, and our interaction models post called the shape of it: the unit of value is shifting from a generated snippet to a running, verified, deployable artifact.

The v0 API makes that artifact addressable by software. A white-labeled app builder, an automated change pipeline triggered from CI or a webhook, and an agent that hands back a working app instead of a code block are the three use cases Vercel names, and all three share one property: they treat v0 as a component in a larger system rather than a destination. That is the architectural line between v0 the product and v0 the platform.

Two honest caveats. First, this is a managed agent service: the workspace, the dev server, and the verification loop all run on Vercel's infra, which is the tradeoff for zero setup but also the lock-in to price. Second, preview tokens are short-lived by design, so any production embedding needs the proxy pattern from the docs; that is a server-side integration, not a copy-paste iframe.

For teams already running agent pipelines, this is the first mainstream app-builder API that ships with a streaming trace, metered usage, and a deployment path as first-class primitives rather than afterthoughts. If you are building agent loops, that is the detail worth studying.

Continue Reading#

• Vercel eve: The Framework for Building AI Agents - where agents live in Vercel's platform, and how eve connections attach tools and keys
• Build Your First Agent with Vercel eve: A Step-by-Step Tutorial - a hands-on walkthrough of the eve stack
• Interaction Models for AI Developer Tools - the design patterns behind snippet, agent, and platform-shaped tools
• The MCP Server Ecosystem: A Developer's Guide - how MCP servers like the new v0 one plug into IDEs and runtimes
• Everything Vercel Shipped at Ship 26 - the wider Vercel agent platform context

Sources#

• Introducing the new v0 API - Vercel Blog, fetched August 5, 2026
• v0 API Overview - v0.app Docs, fetched August 5, 2026
• v0 API Migration Guide (v1 to v2)