v0 API: come usarla per creare e distribuire app

Cosa offre davvero la v0 API

La v0 API trasforma una richiesta in linguaggio naturale in un’app full-stack funzionante, non in un semplice suggerimento di codice. Genera il codice, lo esegue in una Vercel Sandbox, fornisce una preview live protetta e permette di passare direttamente al deployment su Vercel.

Ogni chat v0 funziona come un laboratorio privato dedicato a una singola app. L’ID della chat è la chiave di accesso a quel laboratorio: v0 può leggere, modificare ed eseguire i file al suo interno, mentre ogni messaggio successivo riparte dallo stato corrente. Se la prima richiesta crea una dashboard per classificare i ticket e quella seguente aggiunge una colonna per l’assegnatario, il secondo intervento modifica l’app già presente sul banco di lavoro.

È proprio questo ciclo con stato persistente a fare la differenza. Un normale modello per il codice restituisce del testo e lascia all’utente l’esecuzione. v0 avvia il server di sviluppo, controlla il codice in funzione e, mentre lavora, può individuare e correggere gli errori.

La nuova API v2 ruota attorno a quattro elementi facili da comprendere, senza doverne conoscere il funzionamento interno:

• Chat: conservano file correnti, metadati, impostazioni di privacy e collegamento al progetto Vercel dell’app.
• Messaggi: raccolgono istruzioni e cronologia. Le loro parts, nell’ordine originale, possono mostrare testo, ragionamento, letture e modifiche di file, ricerche, comandi shell, chiamate a tool e azioni dell’agente.
• Preview: sono build in esecuzione, protette da un token di breve durata.
• Deployment: pubblicano su Vercel lo stato corrente della chat.

Ecco perché gli esempi meno recenti possono trarre in inganno. Il quickstart attuale della v2 importa dal pacchetto v0; gli esempi della vecchia v1 importano invece da v0-sdk, e gli ID delle chat v1 non funzionano nella v2.

Come usare la v0 API

Il percorso più breve e sicuro prevede una piccola route server tra l’interfaccia e v0. Il browser invia il prompt dell’utente al server; il server custodisce la chiave API, chiama v0, salva l’ID della chat restituito e rimanda all’interfaccia soltanto il risultato che le serve.

1. Scegliere il punto di partenza giusto

Le opzioni sono tre:

1. Avviare un’interfaccia completa per la generazione di app con npx create-v0-sdk-app.
2. Aggiungere l’SDK server a un prodotto esistente con npm install v0.
3. Collegare un agente già esistente al server MCP remoto di v0, che usa OAuth e non richiede di inserire una chiave API nella configurazione MCP.

Lo starter è il modo più rapido per vedere l’intero schema in azione. Include un’interfaccia chat in React, route proxy lato server, viste dei file generati, un’app di preview isolata e una skill per l’agente v0.

2. Creare la chiave e conservarla sul server

La chiave API si crea nelle impostazioni di v0 e va salvata nell’ambiente server come V0_API_KEY. Non deve comparire nel codice eseguito dal browser né avere il prefisso NEXT_PUBLIC_.

Il wrapper locale può essere avviato con npm run dev, ma le sue route server continueranno a chiamare la v0 API ospitata. Si tratta di un’integrazione eseguita in locale, non di una copia locale del sistema di creazione applicazioni di v0.

3. Creare una chat per ogni app

La prima chiamata avvia sia la conversazione sia il workspace dell’app:

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)

È importante salvare chatId accanto al record del cliente, del workspace o del job nel proprio sistema. Anche i metadati possono raggruppare le chat usando gli stessi identificatori, ma servono a organizzarle, non a controllarne l’accesso.

Non è obbligatorio partire da un prompt vuoto: una chat può nascere da un repository GitHub, da un archivio ZIP o da un insieme di file.

4. Decidere come ricevere il lavoro

Una chiamata sincrona è adatta quando il chiamante può aspettare il risultato completo. Per script, webhook e job CI che devono accodare il lavoro e verificarlo in seguito è preferibile una chiamata asincrona. Lo streaming è invece la scelta giusta quando una persona osserva il processo e l’interfaccia deve mostrare l’agente mentre legge file, modifica codice, esegue comandi e comunica i progressi.

Le risposte di chat e messaggi includono i dati di utilizzo, così al termine di ogni job è possibile registrare il numero di token e il costo in crediti.

5. Usare un proxy per la preview senza esporla direttamente

L’API restituisce un URL di preview e un token di breve durata. Un iframe nel browser non può allegare quel token in modo sicuro; l’architettura documentata inoltra quindi le richieste dell’iframe attraverso un proxy backend sotto il proprio controllo.

Quel proxy va ospitato su un sito riservato alle preview, con un dominio registrabile diverso da quello dell’applicazione principale. Le preview generate possono eseguire codice non attendibile. Il proxy deve inoltre autenticare l’utente corrente e verificare che sia autorizzato ad accedere alla chat richiesta: l’helper di preview di v0 non effettua questa verifica al posto dell’applicazione.

6. Eseguire il deployment soltanto dopo le proprie verifiche

Quando l’app è pronta, v0.chats.deploy({ chatId }) distribuisce su Vercel lo stato corrente della chat. Le variabili d’ambiente appartengono al progetto Vercel collegato e si gestiscono tramite la Vercel API: credenziali del database e chiavi di servizi esterni richiedono quindi un passaggio separato e intenzionale.

Quanto costa

v0 addebita il consumo tramite crediti, non con un prezzo fisso per ogni app generata. I token di input comprendono il prompt, i contenuti caricati, la cronologia della chat, i file sorgente e gli altri elementi di contesto letti da v0. I token di output corrispondono invece a ciò che genera l’agente. Le chat molto lunghe possono quindi diventare più costose man mano che crescono la cronologia e il codice.

Il piano Free costa $0 al mese, include $5 di crediti mensili e prevede un limite giornaliero di sette messaggi. Plus costa $30 per utente al mese e Business $100 per utente al mese; entrambi includono $30 di crediti mensili per utente. Quando i crediti disponibili si esauriscono, la generazione si interrompe.

In un prodotto rivolto ai clienti conviene registrare l’utilizzo restituito da ogni chiamata a chat e messaggi. A ciascun tenant va assegnato un budget, un limite di job o entrambi; altrimenti, un repository particolarmente grande o un ciclo infinito di revisioni può consumare l’intero saldo condiviso.

Sette casi d’uso, ordinati per chi ne ricava più valore

Gli impieghi migliori portano v0 dentro un workflow esistente, dove il prodotto conosce già l’utente, i dati e il tipo di applicazione da realizzare.

Per capire se v0 debba essere il motore sottostante o l’intero prodotto, può essere utile confrontarlo con i migliori AI app builder del 2026. La differenza è sostanziale: un’API ha senso quando si vogliono controllare esperienza del cliente, regole, fatturazione e flusso di revisione.

Tre prodotti che vale la pena costruire

La domanda esiste, ma il mercato dei generatori di app generalisti è già affollato. L’opportunità non è creare un’altra casella vuota per i prompt, bensì un builder che conosca eccezionalmente bene un’attività di valore.

1. La scelta migliore: un app builder verticale dentro un SaaS esistente

Si può creare un generatore vincolato a una singola professione e venderlo come componente aggiuntivo del software che quei clienti usano già. Una piattaforma di gestione immobiliare potrebbe generare portali per i proprietari; una piattaforma logistica, dashboard sulle anomalie delle spedizioni; una piattaforma per il franchising, tracker per l’apertura delle sedi.

La domanda è abbastanza ampia da sostenere la categoria. ai app builder registra circa 12,100 ricerche mensili su Google negli Stati Uniti e il dataset indica una crescita annua del 50%. Ogni mese le persone chiedono agli assistenti AI di build an app with ai circa 392 volte, rispetto alle 231 di agosto 2025: una crescita di circa il 70%. Gli app builder esistenti costano già da $16 a $160 al mese, segno che gli acquirenti accettano un abbonamento software ricorrente per questa esigenza.

La versione minima vendibile richiede due o tre tipi di app approvati, un modulo strutturato per raccogliere i requisiti, una chat v0 per ogni app del cliente, una schermata di revisione in streaming, un proxy sicuro per la preview e un pulsante di deployment controllato da una persona. Il vantaggio difendibile risiede nel modello dati, nei permessi, nei template e nella distribuzione del prodotto host.

Il limite è duro ma utile: un wrapper generalista è quasi indifendibile. Se il prodotto non sa spiegare che cosa conosce del lavoro del cliente che v0, da solo, non conosce, è meglio non costruirlo.

2. Un builder white-label per siti e campagne destinato alle agenzie

L’agenzia può offrire un modulo di raccolta requisiti con il proprio brand, un insieme prestabilito di tipologie di pagina, la propria skill di design system, una coda di revisioni e un passaggio finale per il deployment. Il cliente interagisce con l’esperienza dell’agenzia, mentre v0 gestisce in secondo piano il workspace dell’app e la preview live.

ai website builder registra circa 40,500 ricerche mensili su Google negli Stati Uniti, con una crescita annua del 49% nel dataset. È il bacino più ampio rilevato da questa ricerca, ma segnala anche un mercato pieno di concorrenti competenti. La nicchia utile non è «creare qualsiasi sito», bensì «creare il tipo di sito di questa agenzia, con questo stack, questi componenti e questo processo di approvazione».

Un MVP richiede una configurazione del brand, tre pattern di pagina, il caricamento degli asset, commenti sulla preview e l’approvazione del deployment. Il punto critico è l’assistenza: quando testi, layout, accessibilità o integrazioni generate richiedono correzioni, i clienti ne riterranno responsabile l’agenzia, non v0.

3. Un bot che trasforma le richieste di funzionalità in preview

L’idea è convertire una issue approvata in una possibile modifica già funzionante. Una GitHub App o un webhook interno importa il repository, avvia una chat v0 asincrona, registra l’ID della chat e pubblica la preview nel ticket. Prima di qualsiasi merge o deployment interviene sempre una persona.

Google registra circa 390 ricerche mensili negli Stati Uniti per how to build an app with ai, e il dataset indica una crescita annua dell’86%. A luglio 2026, la domanda presso gli assistenti AI per build an app with ai ha raggiunto 392 prompt mensili. Sono dati che mostrano interesse per applicazioni complete e funzionanti, ma non dimostrano l’esistenza di un mercato CI autonomo. Conviene trattare questo prodotto come una funzionalità per team o un componente aggiuntivo di una piattaforma per sviluppatori, non come un’offerta self-service generalista.

L’MVP comprende un webhook, un elenco consentito di repository, un runner per job asincroni, un archivio delle chat v0, una preview isolata e uno stato di approvazione. Il punto critico è il rischio: il codice generato della preview non è attendibile, l’accesso al repository è sensibile e una demo convincente non dimostra che test, sicurezza, migrazioni e casi limite siano corretti. Il deployment in produzione non deve mai essere l’azione predefinita.

Per una panoramica più ampia della posizione di v0 tra agenti di programmazione e strumenti che trasformano prompt in app, consulta i migliori strumenti di vibe coding del 2026.

Cosa non risolve la v0 API

L’API mette a disposizione un agente che crea app e il suo laboratorio. Tutto il prodotto che li circonda resta responsabilità di chi integra il servizio.

• Non decide che cosa costruire. Una richiesta vaga può comunque produrre una versione ben rifinita della soluzione sbagliata. Servono procedure di raccolta requisiti, template, vincoli e passaggi di revisione adeguati.
• Non gestisce l’autorizzazione dei clienti. L’helper di preview inoltra il traffico, ma spetta all’applicazione decidere chi può accedere a ogni chat.
• Non rende attendibile il codice generato. Le preview vanno erogate da un sito dedicato, su un dominio registrabile diverso, e il codice deve essere verificato prima di arrivare in produzione.
• Non trasferisce le chat v1 nella v2. Bisogna scegliere una versione v1, scaricarla come archivio ZIP e creare da quello stato una nuova chat v2.
• Non sostituisce la Vercel API. Le variabili d’ambiente e diverse operazioni di progetto appartengono al progetto Vercel collegato.
• Non rende fisso il costo. File sorgente, cronologia della conversazione, prompt e output contribuiscono tutti al consumo di token.
• Non è un motore locale per creare app. L’integrazione può essere eseguita in locale, ma il workflow documentato chiama l’API ospitata di v0 ed esegue le preview nell’infrastruttura Vercel.

In sintesi, v0 è indicato quando la preview funzionante e l’iterazione con stato persistente rappresentano il vero vantaggio del prodotto. Se occorre soltanto uno snippet di codice, un componente isolato o una trasformazione di file rigorosamente deterministica, workspace aggiuntivo, proxy, contabilità dei crediti e meccanismo di deployment sono superflui.

Se vuoi progettare e mettere in sicurezza per la produzione un builder basato su v0, sviluppo sistemi AI pronti per la produzione.