> ## 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

# Notifications et push

La boîte de réception intégrée, les préférences de canaux et le pipeline push Expo.

## La boîte de réception et les préférences de canaux

L'onglet notifications liste les notifications de l'espace de travail depuis GET /api/notifications et les marque comme lues par un PATCH sur l'identifiant de la notification. Paramètres → Notifications modifie les préférences de canaux partagées — emailBilling, emailInvites, inAppProduct — via GET et PATCH sur la vue des préférences de la même route, soit le contrat exact utilisé par l'application Web. Le nombre de non lues apparaît sur l'écran d'accueil.


## Enregistrer un appareil pour le push

À la connexion — puis à chaque changement d'espace de travail — l'application demande la permission de notification, résout l'identifiant de projet EAS depuis la configuration de l'application, obtient un jeton push Expo et l'envoie à POST /api/mobile/push-tokens. Android s'enregistre sur le canal par défaut avec une importance élevée.

L'enregistrement rapporte registered, permission_denied ou unavailable et ne lève jamais d'exception — la connexion n'est jamais bloquée par le push. Expo Go et les simulateurs ne peuvent pas terminer l'enregistrement : une couverture réelle exige une build de développement. Le jeton est conservé dans SecureStore (supastack.push.token) pour que la déconnexion puisse le désinscrire avant la destruction du cookie de session.


## Envoi côté serveur et accusés de réception

GET liste les jetons du membre, POST insère ou met à jour un jeton sous l'espace de travail actif, et DELETE le révoque — la liste et la révocation restent à portée utilisateur pour qu'un compte sans espace de travail puisse toujours faire le ménage. Chaque utilisateur conserve au plus vingt jetons d'appareil ; en enregistrer un de plus supprime le plus ancien.

Chaque notification d'espace de travail intégrée est aussi poussée au mieux : le serveur envoie à l'API push Expo par paquets de cent, enregistre les tickets ok et supprime immédiatement les jetons DeviceNotRegistered. Le jeton optionnel EXPO_ACCESS_TOKEN, réservé au serveur, ajoute un en-tête Bearer à ces appels et n'est jamais journalisé. Une planification de plateforme réconcilie les accusés toutes les trente minutes et balaie les tickets périmés — elle repose sur le même déclencheur périodique du planificateur que les autres planifications de la plateforme.

```
# Optional server-only token for authenticated Expo push sends:
# apps/web/.env.local
EXPO_ACCESS_TOKEN=
```


## Toucher une notification ouvre une route de l'application

Les expéditeurs joignent un chemin Web sous data.href. L'application le valide — uniquement des chemins absolus commençant par une barre oblique, de longueur bornée et sans traversal — et associe les chemins connus à des routes natives, par exemple /billing vers /settings/billing et /dashboard vers /home. Une notification touchée hors connexion est mise en tampon puis vidée une fois la connexion terminée.


## Vérification et dépannage

Testez sur une build de développement : accordez puis refusez la permission, basculez le push sous Paramètres → Notifications — l'écran indique cet appareil comme enabled, disabled ou denied — et touchez une notification à froid puis à chaud. Si la désactivation affiche une erreur, la désinscription côté serveur a échoué et l'appareil reste enregistré jusqu'à sa réussite.

[Créer une build de développement](https://supastack.dev/fr/docs/mobile/eas-setup.md)


## Suivant

[Utilisation et crédits](https://supastack.dev/fr/docs/mobile/usage.md)
