Scopes & Ebenen
Berechtigungs-Scopes, ihre Hierarchie und was Partner-Zugaenge sehen.
Jeder Endpunkt verlangt einen Scope. Ein Zugang (Key oder OAuth-Client) darf eine Operation nur aufrufen, wenn sein Scope-Set den geforderten Scope abdeckt.
Scope-Hierarchie
Scopes folgen einer festen Rangfolge — ein hoeherer Scope schliesst die niedrigeren ein:
view < read < edit < delete < publish < manage- view — oeffentliche Teilsicht (anonym, CDN-cachebar)
- read — vollstaendige Lesesicht (angemeldet)
- edit — Anlegen/Aendern
- delete — Loeschen
- publish — Veroeffentlichen
- manage — Verwaltung inkl. Rechtevergabe
Ein Scope ist ein Verb-Objekt-Paar, z. B. read:events, read:locations, read:org.
Dieselbe Route liefert je nach Identitaet unterschiedliche Felder (Field-Projection,
server-autoritativ): anonyme view-Aufrufe sehen nur oeffentliche Felder,
angemeldete read-Aufrufe zusaetzlich die geschuetzten. Zugriff auf die Route allein
gibt also nicht alle Felder frei.
Was Partner sehen
Die Partner-Referenz enthaelt die als partner dokumentierten /v1-Endpunkte.
Die Freigabe einer Route fuer die Partner-Dokumentation ist eine bewusste, im Review
sichtbare Entscheidung im Contract.
Dokumentation ist keine Zugriffsgrenze. Ein API-Schlüssel erreicht jeden Endpunkt,
dessen Scope er trägt — auch solche, die hier nicht beschrieben sind (E-16-AL02). Nie über
Schlüssel: manage-/assign-Scopes, Rechte- und Kontoverwaltung. Sensible Scopes
(Art. 9 DSGVO, Finanzdaten) nur einzeln und ausdrücklich bestätigt. Details:
API-Schlüssel – Umfang & Regeln.
| Scope | Erlaubt |
|---|---|
read:events | Termine lesen |
read:locations | Veranstaltungsorte lesen |
read:org | Gliederung lesen (oeffentliche + geschuetzte Felder) |
Zugang zum Portal
Das Entwicklerportal selbst ist durch zwei Rechte geschuetzt:
read:api-docs— Partner-Fassung lesen (auch fuer befristete Gastkonten von Partner-Entwicklern).read:api-docs:internal— interne Fassung lesen (nur Betreiber; nicht Teil dieses Portals).