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

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

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

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

Санҷидан

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

curl -X PUT https://api.zinndigital.com/v1/sites/{siteId}/php-config \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "values": <object> }'

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

Тафсилот

Applies the **complete** set of overrides. An omitted name is cleared, and `{}` resets every setting to the machine's defaults — deliberately not a PATCH, because *"return this to the platform default"* and *"pin it to the value that default happens to have today"* are different intentions and only a whole-set write can express the first. Values are validated against the **machine's own published range** before the vendor sees them, so a bad value is refused in our words rather than failing later as an unexplained vendor error. The write is then **read back off the machine** and a value it quietly declined is a failure here, never a success the customer discovers is untrue. `409` when the site has no machine to hold the setting. Requires `sites.view` + `sites.panel_access`.

Параметрҳо

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

Ҷавоб

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

401 · 403 · 404 · 409 · 422 · 429 · 503