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 /pt/docs/mobile/notifications.md (or send Accept: text/markdown).
Notificações e push
A caixa de entrada na app, as preferências de canal e o pipeline de push Expo.
A caixa de entrada e as preferências de canal
O separador de notificações lista as notificações do workspace a partir de GET /api/notifications e marca-as como lidas com um PATCH no id da notificação. Configurações → Notificações edita as preferências de canal partilhadas — emailBilling, emailInvites, inAppProduct — através de GET e PATCH na vista de preferências da mesma rota, o contrato exato que a app web usa. A contagem de não lidas aparece no ecrã inicial.
Regista um dispositivo para push
No início de sessão — e outra vez em cada mudança de workspace — a app pede a permissão de notificações, resolve o id de projeto EAS a partir da configuração da app, obtém um Expo push token e envia-o para POST /api/mobile/push-tokens. O Android regista no canal predefinido com importância alta.
O registo reporta registered, permission_denied ou unavailable e nunca lança — o início de sessão nunca é bloqueado pelo push. O Expo Go e os simuladores não conseguem concluir o registo, por isso a cobertura real precisa de um development build. O token fica em SecureStore (supastack.push.token) para que o sign-out o possa desregistar antes de o cookie de sessão ser destruído.
Entrega do servidor e recibos
GET lista os tokens do membro, POST faz upsert de um token debaixo do workspace ativo e DELETE revoga — listar e revogar ficam ao nível do utilizador para que uma conta sem workspace possa na mesma limpar. Cada utilizador guarda no máximo vinte tokens de dispositivo; registar mais um remove o mais antigo.
Cada notificação de workspace na app também é enviada por push em best-effort: o servidor envia para a push API da Expo em blocos de cem, regista os tickets ok e remove os tokens DeviceNotRegistered de imediato. O EXPO_ACCESS_TOKEN opcional, só de servidor, adiciona um cabeçalho Bearer a essas chamadas e nunca é registado. Uma schedule de plataforma reconcilia os recibos a cada trinta minutos e varre os tickets velhos — precisa do mesmo driver de tick do scheduler que as outras schedules de plataforma.
# Optional server-only token for authenticated Expo push sends:
# apps/web/.env.local
EXPO_ACCESS_TOKEN=Os toques em notificações abrem rotas da app
Os remetentes anexam um caminho web como data.href. A app valida-o — só caminhos absolutos com barra, comprimento limitado, sem traversal — e mapeia caminhos conhecidos para rotas nativas, por exemplo /billing para /settings/billing e /dashboard para /home. Um toque que chega sem sessão iniciada fica em buffer e é descarregado depois de o início de sessão concluir.
Verificação e resolução de problemas
Testa num development build: concede e nega a permissão, alterna o push em Configurações → Notificações — o ecrã reporta este dispositivo como enabled, disabled ou denied — e toca numa notificação a frio e a quente. Se desligar mostrar um erro, o unregister do lado do servidor falhou e o dispositivo fica registado até conseguir.