For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/mobile/api.md (or send Accept: text/markdown).
API mobile
Come l'app parla al server — sessioni, raggiungibilità e payload.
Procedura dettagliata per principianti
Prerequisiti: leggere le due guide per principianti riportate di seguito e completare la configurazione locale mobile. Inserisci i valori Expo in apps/mobile/.env.local; imposta EXPO_PUBLIC_API_URL su un host backend raggiungibile dal tuo dispositivo. Un checkout solo mobile non ha un backend web, quindi avvialo o collegane uno separatamente. Un'esportazione Expo riuscita dimostra il pacchetto JavaScript, non l'accettazione del dispositivo o dell'acquisto.
Termini rapidi: uno spazio di lavoro è costituito da utenti, dati e impostazioni separati di un team. Il server è il backend affidabile; mantenere le chiavi del provider fuori dal browser e dal codice del telefono. Una migrazione è una modifica del database con versione che crea o aggiorna tabelle. Un modello AI è il motore che risponde; il catalogo dei modelli è l'elenco del server degli ID e dei prezzi dei modelli disponibili. Un fornitore è un servizio esterno come un servizio di intelligenza artificiale, posta elettronica o fatturazione. Un diritto è una concessione che consente a un'area di lavoro di utilizzare una funzionalità. Un webhook è un messaggio che un servizio invia allo URL di un altro servizio.
1. In apps/mobile/.env.local, impostare EXPO_PUBLIC_API_URL sull'indirizzo backend in esecuzione raggiungibile dal telefono; non utilizzare localhost da un dispositivo fisico.
2. Seguire Configurazione locale mobile per avviare Expo, accedere e aprire l'area di lavoro, le impostazioni e le schermate di chat.
3. Aspettatevi dati autenticati dallo stesso spazio di lavoro. Se è richiesto un timeout, controlla la rete del telefono e del computer e avvia il backend separatamente in un checkout solo mobile.
Per il codice personalizzato, inizia con prompts/README.md in dotazione e copia il prompt più vicino: prompts/new-app-screen.md per la schermata di un'app o prompts/new-landing-page.md per una pagina pubblica. Per il lavoro su server, database o provider, assegna al tuo agente di codifica il compito di questa guida e chiedigli di leggere AGENTS.md, .ai/PROJECT_CONTEXT.md e i mirror .ai/ corrispondenti; controllare gli esatti file sorgente nominati qui; elencare file e controlli prima della modifica; preservare la proprietà dello spazio di lavoro e i segreti solo del server; e mostrarti la differenza. Indicagli il comportamento desiderato, i campi di input e output, i ruoli consentiti, i successi e gli errori previsti e l'account, il fornitore o il dispositivo di prova. Utilizzare valori campione; non incollare mai un vero segreto.
Comprendere l'ambito nativo
Expo include autenticazione/sessione nativa e collegamenti diretti insieme all'area di lavoro, alle impostazioni, alla chat e alle superfici di acquisto RevenueCat. Il comportamento aziendale condiviso e l'autorizzazione rimangono nel backend/pacchetti web; i client nativi in apps/mobile/src chiamano tali API senza incorporare le credenziali del provider.
Utilizza BFF autenticato dalla sessione
I percorsi /api/mobile coprono diritti, disponibilità di acquisto RevenueCat e sincronizzazione del server, organizzazione, membri, inviti, audit, chiavi API, webhook, domini, pianificazioni e richieste di funzionalità. Conservano la proprietà dell'area di lavoro e i controlli dei ruoli. Sono diversi dal contratto pubblico sk_ con chiave al portatore /api/v1.
Utilizza il tuo EXPO_PUBLIC_API_URL raggiungibile dal dispositivo e l'origine/schema configurato; Le variabili pubbliche Expo non contengono mai le credenziali del provider.
Verifica su target nativi
Controlla gli stati di caricamento/errore/vuoto, riconnessione, sessione scaduta, azioni di gestione vietate e resi di deep-link sul dispositivo/build che intendi supportare. Un'esportazione Expo dimostra il raggruppamento, non la consegna nativa o l'accettazione dell'acquisto.
Installazione e configurazione
L'app chiama l'API sotto /api/mobile e la superficie versionata /api/v1 con la sessione del membro invece delle assunzioni sui cookie dell'app web. EXPO_PUBLIC_API_URL è l'unica origine che il client conosce; è pubblica per design e non porta secret.
I token di sessione vengono dal flusso Better Auth Expo e sono mantenuti nello storage sicuro nativo — mai in AsyncStorage in chiaro o nella configurazione in bundle.
GET /api/mobile/entitlement # access state for the member
GET /api/mobile/organization # active workspace context
GET /api/mobile/usage # current-month AI spend, meter caps, and credit balance
GET /api/mobile/appearance # synced appearance bundle (GET/PUT)
POST /api/v1/ai-tasks # authorized work, same as web
Session: /api/auth/* (Better Auth Expo flow)
# Optional server-only token for authenticated Expo push sends:
# EXPO_ACCESS_TOKEN=Flusso di implementazione
Risolvi la sessione archiviata prima della prima richiesta autenticata, aggiornala quando il server segnala la scadenza, e disconnetti pulitamente quando viene revocata. Tratta API irraggiungibile e sessione non valida come stati diversi — uno riprova, l'altro torna all'accesso.
Mantieni i payload identici al contratto web: il server applica le stesse regole di workspace, entitlement e validazione indipendentemente da quale client ha chiamato.
Verifica e risoluzione dei problemi
Testa i fallimenti in modalità aereo, i token scaduti a metà sessione, le sessioni revocate e un avvio a freddo con un token valido archiviato. Una richiesta che fallisce chiusa (negata) è corretta; una che fallisce aperta è un bug da correggere prima del release.