Aktive SupportAccessRequests + 30-Tage-History für den aktuellen Mandanten. Portal: OWNER/MANAGER.
/api/tenant/support-access/[requestId]/revoke
POST
SupportAccessRequest widerrufen. Cascade: DATA_VIEW-Widerruf entzieht auch TENANT_ACCESS. Audit-Log SUPPORT_ACCESS_REVOKED.
DSGVO-Maskierung: Ohne aktiven Support-Zugang werden personenbezogene Daten (E-Mail, Name) in allen Admin-API-Responses maskiert. In der globalen Benutzerliste (/api/admin/users ohne tenantId-Filter) sind PII immer maskiert.
Ticket ohne Authentifizierung erstellen (Rate-limited: 5/Stunde). Für öffentliche Support-Seite
/api/support/[id]
GET/PUT
Einzelnes Ticket. PII-Maskierung basierend auf SupportAccessRequest-Status (ADR-PS-306)
/api/support/[id]/access/request
POST
Support-Zugriffsanfrage erstellen (DATA_VIEW oder TENANT_ACCESS). Auto-Split bei TENANT_ACCESS (ADR-PS-306)
/api/support/[id]/access/[requestId]/grant
POST
Zugriffsanfrage gewähren. Zwei-Tier-Auth: Orphaned User oder Tenant OWNER/MANAGER (ADR-PS-306)
/api/support/[id]/access/[requestId]/deny
POST
Zugriffsanfrage ablehnen. CASCADE: DATA_VIEW-Deny entzieht auch TENANT_ACCESS (ADR-PS-306)
/api/support/[id]/claim
POST
Ticket beanspruchen (SUPPORT/ADMIN). Setzt Status auf ASSIGNED (ADR-PS-306)
/api/support/[id]/reassign
POST
Ticket neu zuweisen (ADMIN). Widerruft alle Zugänge des bisherigen Bearbeiters (ADR-PS-306)
/api/support/[id]/reply
POST
Antwort auf Ticket. Optional: newStatus (z.B. RESOLVED, CLOSED) für Manager – setzt den Ticket-Status direkt in der DB. Auto-Revoke des Datenzugangs bei RESOLVED/CLOSED
Geschuetzte Subdomains (Portal, Admin, Go) verwenden ein Auth-First Pattern: Unauthentifizierte Requests auf beliebige Pfade erhalten einen HTTP 307 Redirect zur Login-Seite – nicht 404. Dies ist ein Sicherheitsprinzip, das verhindert, dass Applikationsstruktur an unauthentifizierte Nutzer preisgegeben wird.
Alle Marketing-Seiten (www) verwenden NextSeo fuer OpenGraph und Twitter Meta-Tags:
Default-Konfiguration in next-seo.config.ts (og:type, og:locale, og:siteName, og:image /icons/icon-512.png 512x512, Twitter summary_large_image). Fallback-Rewrites fuer /images/og-image.jpg und /images/og-image.png in next.config.mjs (ADR-PS-265/269).
Per-Page Overrides mit <NextSeo openGraph=\{\{...\}\} /> fuer Titel, Beschreibung und Canonical-URL.
Language-Alternates (DE, EN, FR, IT) fuer internationale SEO.
SSR-Rendering: OG- und Twitter-Meta-Tags werden server-seitig im initialen HTML gerendert, sodass Crawler (Google, Facebook, Twitter, LinkedIn) und Tools wie curl korrekte Vorschauen erhalten (ADR-PS-254).
4 themenspezifische SEO-Landingpages fuer den CH-Markt:
URL
Hauptkeyword
Slug
/parkraummanagement-wohnanlagen
Parkraummanagement Wohnanlagen
parkraummanagement
/besucherparkplaetze-verwalten
Besucherparkplaetze verwalten
besucherparkplaetze
/falschparker-loesen
Falschparker loesen
falschparker
/parkplatz-software-schweiz
Parkplatz-Software Schweiz
parkplatzSoftware
Jede Seite hat: Hero, Problem (mit Bullet-Points), Solution, Benefits Grid (6 Cards), USP-Highlight (Bewohner-Crowdsourcing), Social Proof, FAQ (5 Fragen, JSON-LD FAQPage Schema), CTA, Related Topics. Alle Texte in DE/EN/FR/IT via src/locales/*/seoLanding.ts. Wiederverwendbares Layout: src/components/marketing/landing/SeoLandingPage.tsx.
SSR-Architektur (ADR-PS-270): Content wird server-seitig via getSeoLandingData() in getServerSideProps aufgeloest und als typisierte Props an die Komponenten uebergeben. Dadurch enthaelt der initiale HTML-Response den vollstaendigen Content (800+ Woerter), korrekte JSON-LD Schemas (SoftwareApplication + FAQPage) und Meta-Tags mit echten Texten – wichtig fuer Crawler (Google, Facebook, etc.). Die Komponenten nutzen kein useTranslation() fuer SEO-Inhalte.