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 /fr/docs/mobile/api.md (or send Accept: text/markdown).
API mobile
Comment l'app parle au serveur — sessions, joignabilité et payloads.
Parcours pas à pas pour débuter
Prérequis : lisez les deux guides pour débuter ci-dessous et terminez la configuration locale Mobile. Les valeurs Expo se trouvent dans apps/mobile/.env.local ; définissez EXPO_PUBLIC_API_URL sur un hôte backend joignable depuis votre appareil. Une copie Mobile seule ne contient pas de backend Web ; démarrez-en ou connectez-en un séparément. Un export Expo réussi prouve uniquement le bundle JavaScript, pas l’acceptation sur appareil ni les achats.
Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.
1. Dans apps/mobile/.env.local, définissez EXPO_PUBLIC_API_URL sur l'adresse backend en cours d'exécution accessible depuis votre téléphone ; n'utilisez pas le localhost à partir d'un appareil physique.
2. Suivez la configuration locale de Mobile pour démarrer Expo, connectez-vous et ouvrez l'espace de travail, les paramètres et les écrans de discussion.
3. Attendez-vous à des données authentifiées provenant du même espace de travail. Si les demandes expirent, vérifiez le réseau téléphonique et informatique et démarrez le backend séparément lors d'un paiement uniquement mobile.
Pour le code personnalisé, commencez par le prompts/README.md fourni et copiez l'invite la plus proche : prompts/new-app-screen.md pour un écran d'application ou prompts/new-landing-page.md pour une page publique. Pour le travail sur un serveur, une base de données ou un fournisseur, confiez à votre agent de codage la tâche de ce guide et demandez-lui de lire les miroirs AGENTS.md, .ai/PROJECT_CONTEXT.md et .ai/ correspondants ; inspectez les fichiers sources exacts nommés ici ; lister les fichiers et les vérifications avant de les modifier ; préserver la propriété de l'espace de travail et les secrets du serveur ; et je vous montre la différence. Indiquez-lui le comportement souhaité, les champs d'entrée et de sortie, les rôles autorisés, les succès et erreurs attendus, ainsi que le compte, le fournisseur ou l'appareil de test. Utilisez des exemples de valeurs ; ne collez jamais un vrai secret.
Comprendre la portée native
Expo comprend l’authentification/session natives et les liens profonds, ainsi que les surfaces d’espace de travail, paramètres, chat et achats RevenueCat. Le comportement partagé et l’autorisation restent dans le backend Web et les packages ; les clients natifs de apps/mobile/src appellent ces API sans intégrer d’identifiants fournisseur.
Utiliser le BFF authentifié par session
Les routes /api/mobile couvrent les droits, la disponibilité des achats RevenueCat et leur synchronisation serveur, les organisations, membres, invitations, audits, clés API, webhooks, domaines, planifications et demandes de fonctionnalités. Elles respectent l’appartenance à l’espace de travail et les contrôles de rôle. Elles sont distinctes du contrat public avec clé Bearer sk_ /api/v1.
Utilisez EXPO_PUBLIC_API_URL accessible depuis l’appareil et l’origine/schéma configurés ; les variables publiques Expo ne contiennent jamais d’identifiants de fournisseur.
Vérifier sur les cibles natives
Sur l’appareil et la compilation visés, vérifiez les états de chargement, d’erreur et de vide, la reconnexion, la session expirée, les actions de gestion interdites et les retours de liens profonds. Une exportation Expo valide l’empaquetage, pas la livraison native ni l’acceptation des achats.
Configuration et paramètres
L'app appelle l'API sous /api/mobile et la surface versionnée /api/v1 avec la session du membre plutôt que des suppositions de cookies issues de l'app web. EXPO_PUBLIC_API_URL est la seule origine que le client connaît ; elle est publique par design et ne porte aucun secret.
Les tokens de session viennent du flux Better Auth Expo et sont gardés dans le stockage sécurisé natif — jamais dans de l'AsyncStorage en clair ni dans la configuration bundlée.
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=Processus d’implémentation
Résolvez la session stockée avant la première requête authentifiée, rafraîchissez-la quand le serveur signale l'expiration, et déconnectez proprement quand elle est révoquée. Traitez API injoignable et session invalide comme des états différents — l'un retente, l'autre revient à la connexion.
Gardez les payloads identiques au contrat web : le serveur applique les mêmes règles de workspace, d'entitlement et de validation quel que soit le client appelant.
Vérification et dépannage
Testez les échecs en mode avion, les tokens expirés en pleine session, les sessions révoquées et un démarrage à froid avec un token valide stocké. Une requête qui échoue fermée (refusée) est correcte ; une qui échoue ouverte est un bug à corriger avant la release.