Kundenportal Vorschau

Geplantes Portal für API-Keys, Geräte und Historie.

Das GetMeNotified Kundenportal ist als spätere Oberfläche für Verwaltung, Übersicht und Auswertung geplant. Die API- und App-Basis ist bereits vorhanden; das Portal wird bewusst separat und schrittweise aufgebaut.

Kundenportal-Basis ist für Beta-Nutzung vorbereitet

Das geschützte Kundenportal ist als erste Beta-Version verfügbar. Angemeldete Kunden können dort API-Keys, verknüpfte Geräte, Link-Codes, Benachrichtigungshistorie und einfache Statistiken einsehen.

Der Portalzugang ist aktuell noch nicht als öffentliche Selbstregistrierung gedacht, sondern für vorbereitete Beta-/Testkunden.

Aktueller Status

Diese Seite beschreibt das geplante Kundenportal. Es gibt aktuell noch keinen öffentlichen Login, keine Self-Service-Buchung und keine automatische API-Key-Erstellung über die Website.

Bereits technisch vorhanden: API-Keys mit Hash-Speicherung, Geräteverknüpfung per Link-Code, Push-Versand an aktive Kundengeräte, Backend-Historie, Detailabruf, lokale App-Historie, Statistiken und Rate-Limiting.
Noch nicht öffentlich aktiv: Portal-Login, Benutzerverwaltung, API-Key-Verwaltung im Browser, Rechnungs-/Aboverwaltung und Self-Service-Onboarding.

Geplante Portalbereiche

API-Zugänge

API-Keys verwalten

Kunden sollen später eigene API-Keys sehen, neue Keys erzeugen und bestehende Keys deaktivieren oder widerrufen können.

  • Status: aktiv, deaktiviert, widerrufen
  • Anzeige ohne Klartext-Key nach Erstellung
  • Zuordnung zu Kunde und Anwendung
  • Nutzung und letzte Verwendung
Geräte

Geräteübersicht

Verknüpfte Geräte sollen sichtbar und verwaltbar werden, ohne FCM-Tokens oder technische Secrets offenzulegen.

  • aktive Kundengeräte
  • Anzeigename und Plattform
  • letzte Registrierung / letzter Kontakt
  • später deaktivieren oder umbenennen
Link-Codes

Geräte verbinden

Link-Codes sollen später im Portal erzeugt werden, damit neue App-Installationen einem Kunden zugeordnet werden können.

  • zeitlich begrenzte Codes
  • maximale Nutzungen
  • Status: aktiv, deaktiviert, widerrufen
  • Hash-Speicherung statt Klartext in der Datenbank
Historie

Benachrichtigungen ansehen

Die vorhandenen History-Endpunkte können später als Portalansicht für versendete Benachrichtigungen genutzt werden.

  • Liste der letzten Requests
  • Detaildaten pro request_uid
  • Delivery-Status ohne FCM-Token
  • Filter nach Zeitraum, Status oder Quelle
Nutzung

Rate-Limits und Verbrauch

Das bestehende technische Logging kann später für Nutzungsanzeigen, Limits und betriebliche Auswertungen verwendet werden.

  • aktuelles Limit: 30 Requests pro 60 Sekunden pro API-Key
  • Anzeige von 429-Ereignissen
  • Requests pro Zeitraum
  • spätere Paketgrenzen
Auswertung

Statistiken vorbereiten

Strukturierte Datenfelder wie amount, currency, type oder duration können später für Portal-Auswertungen genutzt werden.

  • Umsatzsummen
  • Störungsdauer
  • Gruppierungen nach Typ, Gruppe oder Kategorie
  • später Export oder Berichte

Sicherheitsgrundsätze

  • API-Keys werden nicht im Klartext gespeichert.
  • Link-Codes werden normalisiert und nur als Hash gespeichert.
  • FCM-Tokens sollen im Portal nicht angezeigt werden.
  • History-Details zeigen keine internen FCM-Message-IDs.
  • Logdaten sollen nur technische Hashes und Statusinformationen enthalten.

Bewusste Abgrenzung

  • Diese Seite ist noch kein Login-Bereich.
  • Es gibt noch keine öffentliche Registrierung.
  • Es gibt noch keine Self-Service-Zahlung.
  • Bestehende API- und Push-Funktionen werden nicht unnötig verändert.
  • Portal-Funktionen werden erst in kleinen, testbaren Schritten umgesetzt.

Mögliche Umsetzungsphasen

1

Interne Portalbasis

Geschützte Admin-/Kundenansicht, nur für Testbetrieb. Fokus auf API-Keys, Geräte und Link-Codes.

2

Kundenansicht

Kundenlogin, eigene Geräte, eigene Keys, Benachrichtigungshistorie und einfache Nutzungsauswertung.

3

Produktisierung

Paketlogik, Abrechnung, weitere Limits, Exportfunktionen und spätere Module wie ein Windows-Agent.