support
POST /v1/sites/{siteId}/diagnose
Run the support AI against one site — check it, fix what is fixable, record the rest.
توثيقِ شناخت
ایک بیرر ٹوکن کے طور پر ایک API کی بھیجیں۔ کی کے پاس hosting.php.manage اجازت ہونی چاہیے؛ اس کے بغیر کی کو 404 کے بجائے 403 کے ساتھ مسترد کر دیا جاتا ہے۔
یہ اینڈ پوائنٹ کوئی آرگنائزیشن آئی ڈی نہیں لیتا۔ آپ کی کلید پہلے ہی اس آرگنائزیشن کی شناخت کرتی ہے جس سے یہ تعلق رکھتی ہے، اور اس کا جواب اسی کے مطابق محدود ہوتا ہے۔
آزمائیں
کوئی بھی چیز جو زاویہ دار قوسین میں ہو اسے اپنی اقدار سے بدلیں، اور کلیدی پلیس ہولڈر کو اپنے ڈیش بورڈ کی کسی کلید سے بدلیں۔
curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/diagnose \
-H "Authorization: Bearer zdk_live_…" \
-H "Content-Type: application/json" \
-d '{ }'لاگ ان ہیں؟ آپ کے ڈیش بورڈ میں موجود API کنسول آپ کی حقیقی تنظیم کی آئی ڈی اور آپ کی اپنی کلید خود بخود پُر کر دیتا ہے، اور لائیو API پر درخواست چلاتا ہے تاکہ آپ اصل ردعمل دیکھ سکیں۔ اس اینڈ پوائنٹ کو API کنسول میں کھولیں
تفصیلات
Runs every diagnostic probe against the named site: whether it is being throttled by its plan's LVE limits (the cause of `508 Resource Limit Is Reached`), whether a `php.ini` value is below what the plan already allows, whether it runs a retired PHP version, and how much of its disk allowance is used. Remedies on the platform's named safe list are then applied — audit-logged and reversible — and everything that cannot be fixed becomes a **recommendation** the customer and staff can both see. ⛔⛔ **A remedy can never grant a limit the plan does not include.** Every one runs through the same customer-band service a person would use, and an application that moved what the site is entitled to is refused rather than reported as applied. ⛔ `complete` is `false` and `blind_probes` names what could not be read. "We found nothing wrong" and "we could not look" are different answers and the client must render them differently. Requires `hosting.php.manage`.
پیرامیٹرز
| نام | قسم | لازمی | یہ کیا ہے |
|---|---|---|---|
siteId (path) | Uuid | ہاں | The site to check. |
درخواست کا باڈی
| نام | قسم | لازمی | یہ کیا ہے |
|---|---|---|---|
apply_fixes | boolean | نہیں | Set `false` to diagnose without applying anything. The default applies the safe list, which is the platform's ruled behaviour. |
جواب
| نام | قسم | لازمی | یہ کیا ہے |
|---|---|---|---|
complete | boolean | ہاں | False when any probe could not run. |
blind_probes | string[] | ہاں | The probes that could not look. |
probes | SiteDiagnosticProbe[] | ہاں | — |
findings | TicketDeflectionFinding[] | ہاں | — |
applied | string[] | ہاں | Remedies applied automatically, by key. Every one is audit-logged. |
refused | object[] | نہیں | Remedies that were attempted and refused, with the reason code. `ENTITLEMENT_DRIFT` means the platform detected that a fix would have changed what the site is entitled to and st… |
recommendations | SupportRecommendation[] | ہاں | — |
notified | integer | نہیں | How many customers were e-mailed. At most one message per finding, ever. |
notify_skipped_not_in_good_standing | integer | نہیں | Notifications skipped because the account is suspended or unpaid. ⛔ Counted rather than silently dropped — a skip and a broken emitter look identical otherwise. |
notify_failed | integer | نہیں | Notifications that were attempted and raised. ⛔ Its own number: a broken emitter and a quiet run both report `notified: 0`, so a customer who was never told would otherwise be i… |
وہ خرابیان جو یہ اینڈ پوائنٹ واپس کر سکتا ہے
401 · 403 · 404 · 422