hosting
GET /v1/sites/{siteId}/diagnostics
Run the site's health checks and report each one.
Authentication
Send an API key as a bearer token. The key must carry the sites.view permission; a key without it is refused with 403, not 404.
This endpoint takes no organisation id. Your key already identifies the organisation it belongs to, and the response is scoped to it.
Try it
Replace anything in angle brackets with your own values, and the key placeholder with a key from your dashboard.
curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/diagnostics \
-H "Authorization: Bearer zdk_live_…"Signed in? The API console in your dashboard fills in your real organisation id and your own key, and runs the request against the live API so you can see the actual response. Open this endpoint in the API console
Details
The equivalent of the hosting panel's own auto-diagnostics page: nameservers, mail DNS, a live TLS fetch, domain reputation across five blocklists, the last malware scan, file permissions and the error log. ⛔ Not one vendor endpoint — an aggregate of six concurrent reads, which is why each row carries its **own** state. A check that could not run reports `unknown`, deliberately distinct from `ok`: collapsing them would reassure a customer about something never checked. ⛔ Rows carry keys and data, never prose — the sentence is the client's to translate. Requires `sites.view`.
Parameters
| Name | Type | Required | What it is |
|---|---|---|---|
siteId (path) | Uuid | Yes | Site ID (UUIDv7). |
Response
| Name | Type | Required | What it is |
|---|---|---|---|
data | SiteDiagnostic[] | Yes | — |
worst | string<ok, warn, fail, unknown> | Yes | The most serious state present, for a summary badge. `unknown` ranks above `ok` and below `warn`. |
checks | string[] | Yes | Every check key, in display order, so a client can render a stable list. |
states | string[] | Yes | — |
Errors this endpoint can return
401 · 403 · 404 · 429 · 503