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 /de/docs/mobile/notifications.md (or send Accept: text/markdown).
Mitteilungen und Push
Der In-App-Posteingang, die Kanal-Einstellungen und die Expo-Push-Pipeline.
Posteingang und Kanal-Einstellungen
Der Mitteilungen-Tab listet Workspace-Mitteilungen aus GET /api/notifications und markiert sie per PATCH auf der Mitteilungs-ID als gelesen. Einstellungen → Mitteilungen bearbeitet die gemeinsamen Kanal-Einstellungen — emailBilling, emailInvites, inAppProduct — über GET und PATCH auf der Preferences-Ansicht derselben Route, also genau den Vertrag, den die Web-App nutzt. Die Ungelesen-Zahl erscheint auf dem Home-Bildschirm.
Ein Gerät für Push registrieren
Bei der Anmeldung — und erneut bei jedem Workspace-Wechsel — fragt die App die Mitteilungsberechtigung an, löst die EAS-Projekt-ID aus der App-Konfiguration auf, holt ein Expo-Push-Token und postet es an POST /api/mobile/push-tokens. Android registriert auf dem Standardkanal mit hoher Wichtigkeit.
Die Registrierung meldet registered, permission_denied oder unavailable und wirft nie — die Anmeldung wird nie durch Push blockiert. Expo Go und Simulatoren können die Registrierung nicht abschließen; echte Abdeckung braucht daher einen Development-Build. Das Token liegt im SecureStore (supastack.push.token), damit die Abmeldung es abmelden kann, bevor das Sitzungs-Cookie zerstört wird.
Server-Zustellung und Quittungen
GET listet die Tokens des Mitglieds, POST legt ein Token unter dem aktiven Arbeitsbereich an oder aktualisiert es, und DELETE widerruft — Auflisten und Widerrufen bleiben benutzerbezogen, damit auch ein workspace-loses Konto aufräumen kann. Jeder Benutzer behält höchstens 20 Geräte-Tokens; die Registrierung eines weiteren entfernt das älteste.
Jede In-App-Workspace-Mitteilung wird zusätzlich best-effort gepusht: Der Server sendet in Blöcken von je 100 an die Expo-Push-API, protokolliert ok-Tickets und entfernt DeviceNotRegistered-Tokens sofort. Das optionale, rein serverseitige EXPO_ACCESS_TOKEN fügt diesen Aufrufen einen Bearer-Header hinzu und wird nie geloggt. Ein Plattform-Zeitplan gleicht die Quittungen alle 30 Minuten ab und räumt veraltete Tickets weg — er braucht denselben Scheduler-Tick-Treiber wie die anderen Plattform-Zeitpläne.
# Optional server-only token for authenticated Expo push sends:
# apps/web/.env.local
EXPO_ACCESS_TOKEN=Mitteilungs-Tipps öffnen App-Routen
Absender hängen einen Web-Pfad als data.href an. Die App validiert ihn — nur absolute Slash-Pfade, begrenzte Länge, kein Traversal — und bildet bekannte Pfade auf native Routen ab, etwa /billing auf /settings/billing und /dashboard auf /home. Ein Tipp, der im abgemeldeten Zustand eintrifft, wird zwischengespeichert und nach abgeschlossener Anmeldung ausgeführt.
Überprüfung und Fehlerbehebung
Testen Sie auf einem Development-Build: Berechtigung erteilen und verweigern, Push unter Einstellungen → Mitteilungen umschalten — der Bildschirm meldet dieses Gerät als enabled, disabled oder denied — und eine Mitteilung kalt und warm antippen. Zeigt das Ausschalten einen Fehler, ist die serverseitige Abmeldung fehlgeschlagen, und das Gerät bleibt registriert, bis sie gelingt.