21. API Keys ❌

Nicht implementiert. PRONTO hat kein API-Key-System — es gibt keine Verwaltungsseite, um Schlüssel zu erzeugen, anzuzeigen oder zu widerrufen, und kein Datenmodell für Kunden-API-Keys.

Warum die öffentlichen Endpunkte trotzdem ohne Key funktionieren

Die in 20-api.md dokumentierten Endpunkte (Buchungsseiten, Formulare, Newsletter, Chat-Widget) sind bewusst ohne Authentifizierung nutzbar, weil sie genau das öffentliche Verhalten abbilden, das sie auf einer Website ohnehin hätten — ein Formular oder eine Buchungsseite ist für jeden Website-Besucher offen, unabhängig davon, ob PRONTO oder eine eigene Lösung dahintersteht. Der Schutz vor Missbrauch erfolgt nicht über einen Schlüssel, sondern über:

• Tenant-Isolation durch die mitgesendete workspace/kundeId — jeder Endpunkt liefert und schreibt ausschließlich Daten des referenzierten Kunden.
• Honeypot + Mindest-Ausfüllzeit + IP-Rate-Limit gegen automatisierten Missbrauch (siehe 24-rate-limits.md).
• Service-Role-Zugriff nur serverseitig — der Client hat nie direkten Datenbankzugriff (siehe 25-security.md).

Interne, session-basierte Authentifizierung

Innerhalb der eingeloggten PRONTO-Anwendung selbst (nicht Teil dieser Kunden-API) läuft jede Anfrage über den Supabase-Auth-Session-Token des angemeldeten Nutzers, siehe 22-authentication.md. Das ist kein API-Key-Mechanismus, sondern klassische Session-Authentifizierung für die eigene Web-Oberfläche.