GET /v1/branding

പ്രമാണീകരണം

ബെയറർ ടോക്കണായി ഒരു API കീ അയക്കുക. ഈ എൻഡ്‌പോയിന്റ് അതിന്റെ സ്പെസിഫിക്കേഷനിൽ ഒരു പ്രത്യേക അനുമതി വ്യക്തമാക്കിയിട്ടില്ല, അതിനാൽ അനുമാനിക്കുന്നതിന് പകരം നിങ്ങളുടെ കീയ്ക്ക് ഏറ്റവും കുറഞ്ഞത് ആവശ്യമുള്ളത് നൽകുകയും പ്രതികരണം പരിശോധിക്കുകയും ചെയ്യുക.

ശ്രമിച്ച് നോക്കൂ

കോണമ്ബ്രക്കറ്റുകളിലുള്ള ഏതും നിങ്ങളുടെ സ്വന്തം മൂല്യങ്ങൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക, കീ പ്ലേസ്‌ഹോൾഡർ നിങ്ങളുടെ ഡാഷ്‌ബോർഡിലെ ഒരു കീ ഉപയോഗിച്ചും മാറ്റിസ്ഥാപിക്കുക.

curl -X GET https://api.zinndigital.com/v1/branding \
  -H "Authorization: Bearer zdk_live_…"

സൈൻ ഇൻ ചെയ്തിട്ടുണ്ടോ? നിങ്ങളുടെ ഡാഷ്‌ബോർഡിലെ API കൺസോൾ നിങ്ങളുടെ യഥാർത്ഥ ഓർഗനൈസേഷൻ ഐഡിയും നിങ്ങളുടെ സ്വന്തം കീയും പൂരിപ്പിക്കുകയും, യഥാർത്ഥ പ്രതികരണം (response) നിങ്ങൾക്ക് കാണുന്നതിനായി ലൈവ് API-ലേക്ക് അഭ്യർത്ഥന (request) പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു. ഈ എൻഡ്പോയിന്റ് API കൺസോളിൽ തുറക്കുക

വിശദാംശങ്ങൾ

The name, logo, colour and links the signed-in customer's dashboard paints itself with — their agency's or reseller's if they are white-labelled, otherwise Zinn®'s. **Always answers, for every authenticated caller.** An organisation with no brand of its own is not a `404`: it receives the platform identity with `is_white_label: false`. A nullable answer would make every client invent its own fallback, and the second such client is the leak this feature exists to close. Resolved by walking **up** the organisation tree to the org that owns the brand, and gated on the `white_label` entitlement held by that owner — never by the client reading it, who holds no such entitlement and never will. ⛔ Not gated on a permission key. This answers *"what does your screen look like?"*, not *"may you see this data?"* — the payload is the brand the caller is already looking at. It is still authenticated and org-scoped, so one tenant cannot ask what another tenant's panel looks like. **`Cache-Control: private, no-store`** — this response is never stored, by any cache, and that is a tenancy requirement rather than a tuning choice. The URL is `/v1/branding` for every tenant and the organisation travels in `X-Zinn-Org`, so a stored copy is keyed on nothing that separates one tenant from the next. It was `private, max-age=60` until 2026-08-26; `private` bounds a stored copy to one browser profile and **does not** bound it to one tenant, and one browser profile is exactly where an organisation switch happens. Measured before the change: four organisations, one token, one second apart, all four answering with the first one's brand. `Vary: X-Zinn-Org, Authorization` is sent as well, so an intermediary that stores despite `no-store` still cannot serve one tenant's brand to another.

പരാമീറ്ററുകൾ

പ്രതികരണം

ഈ എൻഡ്‌പോയിന്റ് നൽകാൻ കഴിയുന്ന പിഴവുകൾ

401 · 429