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