hosting
POST /v1/sites/{siteId}/security/scan
Scan a site for malware now.
Санҷиши ҳаққоният
Kalitи API-ро ҳамчун token-и bearer фиристед. Ин нуқтаи ниҳоӣ дар мушаххасот иҷозати мушаххасеро нишон намедиҳад, бинобар ин ба калиди худ ҳадди ақали заруриро диҳед ва ба ҷои тахмин кардан, ҷавобро санҷед.
Ин нуқтаи поёнӣ ягон рақами мушаххаси созмонро талаб намекунад. Калиди шумо аллакай созмонеро, ки ба он тааллуқ дорад, муайян мекунад ва ҷавоб ба он маҳдуд карда мешавад.
Санҷидан
Ҳар чизро дар қаavски кунҷӣ бо қиматҳои худ ва ҷойи нигоҳдорандаи калидро бо калима аз панели идоракунии худ иваз кунед.
curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/security/scan \
-H "Authorization: Bearer zdk_live_…"Воarid шудаед? Консоли API дар панели идоракунии шумо рақами мушаххаси ташкилоти воқеӣ ва калиди худро пур мекунад ва дархостро бар зидди API-и фаъол иҷро мекунад, то шумо посухи воқеиро бубинед. Ин нуқтаи ниҳоиро дар консоли API кушоед
Тафсилот
Queues an on-demand scan and answers `202` with the site's state, which will read `scanning` once the workflow starts. Gated on `sites.view`, not on a write key: asking for a fresh scan of your own site changes nothing about it, and it is the first thing a worried customer does. **Concurrency is bounded by the workflow id, which is per site.** A second request while a scan is running is still a `202` — a scan of this site *is* in progress, which is what was asked for — and no second scan of the same document root starts. `422` when the site is not running (a suspended or still-provisioning site has no document root to scan). `503` when the durable-execution service is unreachable: answering `202` there would flip the card to *scanning…* for a scan that was never started, and the customer would watch a spinner for hours.
Параметрҳо
| Ном | Намуд | Талаб карда мешавад | Ин чӣ аст |
|---|---|---|---|
siteId (path) | Uuid | Бале | Site ID (UUIDv7). |
Ҷавоб
| Ном | Намуд | Талаб карда мешавад | Ин чӣ аст |
|---|---|---|---|
status | MalwareStatus | Бале | A site's scan verdict. There is deliberately **no** `unscanned` member: a site nothing has looked at yet is `clean` with `last_scan_at: null`, which is one nullable timestamp ra… |
last_scan_at | object | Бале | When a scan last **completed**. `null` = never scanned. A scan that failed does not stamp this, so a stale success can never be mistaken for a fresh one. |
detections | MalwareDetection[] | Бале | — |
recent_resolutions | ResolvedMalwareDetection[] | Бале | Findings that were present and are not any more, most recently cleared first — the record of the protection having worked, which an all-clear alone cannot show. `resolved_at` al… |
can_rescan | boolean | Бале | Whether `rescanSite` will accept a request for this site: false while a scan is already running, false for a site that is not running at all (there is no document root to scan),… |
last_scan_error_code | string<, scan_conflict, scanner_unreachable, scanner_missing, scan_failed> | Бале | Why a scan that **ran** could not finish; empty when none has failed. Non-empty means an attempt was made against this site and broke — an unreachable host, a vendor error, a sc… |
unavailable_reason | string | Бале | Why **no scan was attempted**; empty when one was. A stable machine identifier for the client to localise, never a sentence and never a vendor name. `vendor_unsupported` — the h… |
runtime | SiteRuntimeSecurity | Бале | What our runtime sensor saw **happen** on this site, and whether anything was watching it at all. The malware fields above are a verdict on files at rest; this is the other half… |
Хатоҳое, ки ин нуқтаи ниҳоӣ метавонад баргардонад
401 · 403 · 404 · 422 · 429 · 503