> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Mobile API Wie die App mit dem Server spricht — Sessions, Erreichbarkeit und Payloads. ## Schritt-für-Schritt für Einsteiger Voraussetzungen: Lesen Sie die beiden Einsteigeranleitungen unten und schließen Sie die lokale Mobile-Einrichtung ab. Expo-Werte gehören in `apps/mobile/.env.local`; setzen Sie `EXPO_PUBLIC_API_URL` auf einen Backend-Host, den Ihr Gerät erreichen kann. Ein reiner Mobile-Checkout enthält kein Web-Backend; starten oder verbinden Sie eines separat. Ein erfolgreicher Expo-Export belegt nur das JavaScript-Bundle, nicht Geräte- oder Kaufannahme. Kurze Begriffe: Ein Arbeitsbereich umfasst die einzelnen Benutzer, Daten und Einstellungen eines Teams. Der Server ist das vertrauenswürdige Backend; Halten Sie Anbieterschlüssel aus Browser- und Telefoncodes fern. Eine Migration ist eine versionierte Datenbankänderung, die Tabellen erstellt oder aktualisiert. Ein KI-Modell ist der Motor, der antwortet; Der Modellkatalog ist die Liste der verfügbaren Modell-IDs und Preise des Servers. Ein Anbieter ist ein externer Dienst wie ein KI-, E-Mail- oder Abrechnungsdienst. Eine Berechtigung ist eine Bewilligung, die einem Arbeitsbereich die Nutzung einer Funktion ermöglicht. Ein Webhook ist eine Nachricht, die ein Dienst an den URL eines anderen Dienstes sendet. 1. Stellen Sie in `apps/mobile/.env.local` `EXPO_PUBLIC_API_URL` auf die aktuelle Backend-Adresse ein, die von Ihrem Telefon aus erreichbar ist. Verwenden Sie `localhost` nicht von einem physischen Gerät aus. 2. Folgen Sie den lokalen Einrichtungsanweisungen für Mobile, um Expo zu starten, sich anzumelden und Arbeitsbereich, Einstellungen und Chat-Bildschirme zu öffnen. 3. Erwarten Sie authentifizierte Daten aus demselben Arbeitsbereich. Wenn bei Anfragen eine Zeitüberschreitung auftritt, überprüfen Sie das Telefon- und Computernetzwerk und starten Sie das Backend separat in einem rein mobilen Checkout. Beginnen Sie für benutzerdefinierten Code mit dem bereitgestellten `prompts/README.md` und kopieren Sie die nächstgelegene Eingabeaufforderung: `prompts/new-app-screen.md` für einen App-Bildschirm oder `prompts/new-landing-page.md` für eine öffentliche Seite. Geben Sie Ihrem Programmieragenten für Server-, Datenbank- oder Anbieterarbeiten die Aufgabe dieses Handbuchs und bitten Sie ihn, `AGENTS.md`, `.ai/PROJECT_CONTEXT.md` und passende `.ai/`-Spiegel zu lesen; Überprüfen Sie die hier genannten genauen Quelldateien. Listen Sie Dateien auf und prüfen Sie sie vor der Bearbeitung. Bewahren Sie den Arbeitsbereichseigentum und die Nur-Server-Geheimnisse. und zeige dir den Unterschied. Teilen Sie ihm das gewünschte Verhalten, Eingabe- und Ausgabefelder, zulässige Rollen, erwartete Erfolge und Fehler sowie das Testkonto, den Anbieter oder das Gerät mit. Beispielwerte verwenden; Fügen Sie niemals ein echtes Geheimnis ein. [Bevor Sie beginnen](https://supastack.dev/de/docs/web/before-you-start.md) [Terminal-Grundlagen](https://supastack.dev/de/docs/web/terminal-basics.md) [Mobiles lokales Setup](https://supastack.dev/de/docs/mobile/ship-in-5-minutes.md) [Agentenaufforderungen und Projektspeicher](https://supastack.dev/de/docs/web/agents.md) ## Umfang der nativen App verstehen Expo bietet native Authentifizierung/Sitzungen und Deep Links sowie Workspace-, Einstellungs-, Chat- und RevenueCat-Kaufoberflächen. Gemeinsame Geschäftslogik und Autorisierung bleiben im Web-Backend und in den Paketen; native Clients unter `apps/mobile/src` rufen diese APIs auf, ohne Provider-Zugangsdaten einzubetten. ## Das sitzungsbasierte BFF verwenden Die Routen unter `/api/mobile` umfassen Berechtigungen, RevenueCat-Kaufverfügbarkeit und Serversynchronisierung, Organisation, Mitglieder, Einladungen, Audit, API-Schlüssel, Webhooks, Domains, Zeitpläne und Feature Requests. Sie wahren Workspace-Eigentum und Rollenprüfungen. Sie unterscheiden sich vom öffentlichen Vertrag mit Bearer-Schlüssel `sk_` unter `/api/v1`. Verwende die von deinem Gerät erreichbare `EXPO_PUBLIC_API_URL` sowie den konfigurierten Ursprung und das App-Schema. Öffentliche Expo-Variablen enthalten niemals Provider-Zugangsdaten. ## Auf nativen Zielen prüfen Prüfe auf dem vorgesehenen Gerät und Build Lade-, Fehler- und Leerzustände, erneute Verbindung, abgelaufene Sitzung, unzulässige Verwaltungsaktionen und Deep-Link-Rückkehr. Ein Expo-Export belegt das Bündeln, nicht die native Auslieferung oder die Abnahme von Käufen. [Alle API-Routen](https://supastack.dev/de/docs/web/project-structure.md) [Nativer Sitzungsablauf](https://supastack.dev/de/docs/mobile/authentication.md) ## Einrichtung und Konfiguration Die App ruft die API unter /api/mobile und die versionierte /api/v1-Oberfläche mit der Session des Mitglieds auf statt mit Cookie-Annahmen der Web-App. EXPO_PUBLIC_API_URL ist der einzige Origin, den der Client kennt; sie ist by design öffentlich und trägt keine Secrets. Session-Tokens kommen aus dem Better-Auth-Expo-Flow und werden im nativen Secure Storage gehalten — nie in plain AsyncStorage oder gebündelter Config. ``` 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= ``` ## Implementierungsablauf Löse die gespeicherte Session vor dem ersten authentifizierten Request auf, erneuere sie, wenn der Server Ablauf meldet, und melde sauber ab, wenn sie widerrufen wird. Behandle unerreichbare API und ungültige Session als verschiedene Zustände — das eine retryt, das andere kehrt zum Sign-in zurück. Halte Payloads identisch zum Web-Vertrag: Der Server wendet dieselben Workspace-, Entitlement- und Validierungsregeln an, egal welcher Client aufgerufen hat. ## Überprüfung und Fehlerbehebung Teste Flugmodus-Fehler, mitten in der Session abgelaufene Tokens, widerrufene Sessions und einen Cold Start mit gespeichertem gültigem Token. Ein Request, der geschlossen fehlschlägt (verweigert), ist korrekt; einer, der offen fehlschlägt, ist ein Bug, der vor Release zu fixen ist. ## Weiter [Native UI und Theming](https://supastack.dev/de/docs/mobile/ui.md)