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

# Notifiche e push

La posta in arrivo in-app, le preferenze dei canali e la pipeline push Expo.

## La posta in arrivo e le preferenze dei canali

Il tab delle notifiche elenca le notifiche del workspace da GET /api/notifications e le segna come lette con una PATCH sull'id della notifica. Impostazioni → Notifiche modifica le preferenze dei canali condivise — emailBilling, emailInvites, inAppProduct — tramite GET e PATCH sulla vista preferences della stessa rotta, l'esatto contratto che usa l'app web. Il conteggio dei non letti compare sulla schermata home.


## Registra un dispositivo per il push

All'accesso — e di nuovo a ogni cambio di workspace — l'app richiede il permesso per le notifiche, risolve l'id di progetto EAS dalla configurazione dell'app, ottiene un Expo push token e lo invia a POST /api/mobile/push-tokens. Android si registra sul canale predefinito con importanza alta.

La registrazione riporta registered, permission_denied o unavailable e non lancia mai — l'accesso non è mai bloccato dal push. Expo Go e i simulatori non possono completare la registrazione, quindi la copertura reale richiede una build di sviluppo. Il token è conservato in SecureStore (supastack.push.token) così la disconnessione può annullarne la registrazione prima che il cookie di sessione venga distrutto.


## Consegna lato server e ricevute

GET elenca i token del membro, POST inserisce o aggiorna un token sotto il workspace attivo e DELETE revoca — lista e revoca restano nell'ambito utente così un account senza workspace può comunque fare pulizia. Ogni utente conserva al massimo venti token dispositivo; registrarne uno in più elimina il più vecchio.

Ogni notifica di workspace in-app viene anche inviata in push best-effort: il server spedisce alla push API di Expo in blocchi di cento, registra i ticket ok e rimuove subito i token DeviceNotRegistered. L'opzionale EXPO_ACCESS_TOKEN solo server aggiunge un header Bearer a quelle chiamate e non viene mai loggato. Una pianificazione di piattaforma riconcilia le ricevute ogni trenta minuti e ripulisce i ticket obsoleti — richiede lo stesso driver di tick dello scheduler delle altre pianificazioni di piattaforma.

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


## I tocchi sulle notifiche aprono rotte dell'app

I mittenti allegano un percorso web come data.href. L'app lo valida — solo percorsi assoluti con slash, lunghezza limitata, nessun attraversamento — e mappa i percorsi noti su rotte native, ad esempio /billing su /settings/billing e /dashboard su /home. Un tocco che arriva da non autenticati viene messo in coda e consegnato una volta completato l'accesso.


## Verifica e risoluzione dei problemi

Testa su una build di sviluppo: concedi e nega il permesso, attiva/disattiva il push in Impostazioni → Notifiche — la schermata riporta questo dispositivo come enabled, disabled o denied — e tocca una notifica a freddo e a caldo. Se lo spegnimento mostra un errore, la deregistrazione lato server è fallita e il dispositivo resta registrato finché non riesce.

[Compila un client di sviluppo](https://supastack.dev/it/docs/mobile/eas-setup.md)


## Successivo

[Utilizzo e crediti](https://supastack.dev/it/docs/mobile/usage.md)