ZWEI ROUTEN, ZWEI ZWECKE. `GET /api/v1/restaurant` liefert die Stammdaten des Betriebs, zu dem der Schlüssel gehört — vor allem `timezone`, den Bezugsrahmen jeder anderen Antwort der API. `GET /api/v1/branding` liefert das Erscheinungsbild: Logo, Farben, Schriften, Sozial- und Rechtslinks.
BEIDE HÄNGEN AN `website:read` UND AN KEINEM PLAN-MERKMAL. Das Recht sitzt an `website` und nicht an `settings`, weil `settings` einem Schlüssel gar nicht zuweisbar ist — eine Route, die es verlangte, liefe unweigerlich in ein 403. Ausgeliefert wird hier genau das, was ohnehin öffentlich auf der Website steht. Und die fehlende Plan-Schranke ist Absicht: hinge `timezone` an einem Plan, wäre die halbe API für eine Kassenanbindung unbrauchbar.
ES GIBT KEINEN PFADABSCHNITT UND KEIN `?restaurantId=`. Der Betrieb steht ausschliesslich in der Schlüsselzeile. Damit entsteht die Fehlerklasse „fremder Mandant im Pfad" gar nicht erst, statt geprüft zu werden.
DIE ANSCHRIFT IST EIN UNTEROBJEKT. `address.street`, `address.street2`, `address.zipCode`, `address.city`, `address.state` (Bundesland) und `address.country` (ISO 3166-1 alpha-2, z. B. `AT`). Nicht gepflegte Felder sind `null`, nie ein leerer Text.
BRANDING ANTWORTET AUCH DANN MIT 200, WENN ES NOCH KEINS GIBT. Dann stehen überall `null`-Werte, und Name, Untertitel, Beschreibung sowie Logo fallen auf die Stammdaten zurück. „Dieser Betrieb hat noch kein Branding gepflegt" ist eine ANTWORT, kein Fehler — ein 404 zwänge jede Website-Einbindung zu einer Fallunterscheidung, die sie ohnehin gleich behandelte.
DER ANWENDUNGSFALL HINTER `branding` IST DIE BEWERTUNGSANFRAGE. Unter `social.googleReviewUrl` und `social.tripAdvisorUrl` stehen die Adressen, ohne die ein Werkzeug den Gast nirgendwohin schickt. Unter `legal` stehen Impressum, Datenschutzerklärung, AGB und die Umsatzsteuer-Identifikationsnummer.