GET /v1/sites/{siteId}/php-config

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

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

Ин нуқтаи поёнӣ ягон рақами мушаххаси созмонро талаб намекунад. Калиди шумо аллакай созмонеро, ки ба он тааллуқ дорад, муайян мекунад ва ҷавоб ба он маҳдуд карда мешавад.

Санҷидан

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

curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/php-config \
  -H "Authorization: Bearer zdk_live_…"

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

Тафсилот

The `php.ini` settings this site's machine will let a customer change, **as the machine describes them** — each with its type (`bool`/`list`/`value`), its default, the legal values for a list, and a sentence explaining it. ⭐ The schema is the box's, not ours. A hardcoded field list would drift the first time the hosting changed a range and nothing would go red: the write would simply be refused later, at the vendor, in the vendor's words. `value` is `null` when the site is **inheriting** the default rather than having set it — a different fact from setting it to the same text, and the only one of the two that survives a change of the platform default. `supported: false` with an empty `options` list is a real answer, not an error: the hosting may publish no changeable settings at all. `reason` says which silence it is. Requires `sites.view` + `sites.panel_access`.

Параметрҳо

Ҷавоб

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

401 · 403 · 404 · 429 · 503