PUT /v1/reseller/brand

Санҷиши ҳаққоният

Kaliti API-ро ҳамчун рамзи доранда (bearer token) фиристед. Калит бояд дорои иҷозати reseller.manage бошад; калиди бидуни он бо хатои 403 рад карда мешавад, на 404.

Санҷидан

Ҳар чизро дар қаavски кунҷӣ бо қиматҳои худ ва ҷойи нигоҳдорандаи калидро бо калима аз панели идоракунии худ иваз кунед.

curl -X PUT https://api.zinndigital.com/v1/reseller/brand \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "name": <string> }'

Воarid шудаед? Консоли API дар панели идоракунии шумо рақами мушаххаси ташкилоти воқеӣ ва калиди худро пур мекунад ва дархостро бар зидди API-и фаъол иҷро мекунад, то шумо посухи воқеиро бубинед. Ин нуқтаи ниҳоиро дар консоли API кушоед

Тафсилот

Creates or updates your brand. Requires `reseller.manage` — reading your brand is a view permission; changing what every one of your clients sees is not. ⛔ **This endpoint is why white-label was unreachable until 2026-08-16.** The resolver, the entitlement gate, the org-tree walk, the e-mail path and the panel painting were all built and correct, and nothing anywhere could create the row they all read — `Brand` held zero rows across the estate. ⛔ `panel_hostname`, `sending_domain` and `sending_domain_verified` are **refused here, with a sentence saying why**, rather than ignored. All three are facts about the outside world this endpoint cannot establish: a hostname nobody serves is a link to nowhere, an unverified sending domain does not deliver, and a verified flag a customer can set is a wish rather than a verification. Refused with 422 when white-label is not on your plan — storing a brand the resolver would decline to serve is configuration that silently does nothing.

Параметрҳо

Ҷисми дархост

Ҷавоб

Хатоҳое, ки ин нуқтаи ниҳоӣ метавонад баргардонад

401 · 403 · 404 · 422 · 429