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 /de/docs/mobile/api.md (or send Accept: text/markdown).
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.
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.
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.