POST · Security
Read or act on Imunify360 malware findings
Read or act on Imunify360 malware findings
/api/v1/security/imunify/scan
Description
action=summary returns protection status and counts; findings returns the detected items; scan starts an on-demand scan; ignore accepts a finding; restore puts a quarantined file back and is irreversible — it returns {status:"confirmation_required", confirmationUrl, …} and restores nothing on this call. On a node without Imunify360 every action returns supported:false.
Body
Send as application/json.
| Name | Type | Description |
|---|---|---|
input
required
|
string |
A domain, email address, website URL, or Inleed service id — for example example.se, [email protected] or 42976. Resolved to the owning account automatically, and the resolved target is echoed back in the response.
|
action
required
|
enum |
summary status+counts, findings the items, scan a new scan, ignore a finding, or restore a quarantined file (confirmation-tier). scan/ignore/restore need write:hosting. One of summary, findings, scan, restore, ignore.
|
finding_id
|
string |
The finding to restore or ignore, from action=findings. Letters, digits and ._- only.
|
limit
|
integer |
For findings: maximum items to return (1–200). Omit for the node default.
|
path
|
string |
For scan: an optional path under the account to scan. Omit to scan the account.
|
attempt_key
|
string |
An idempotency key you choose for a restore. Reusing it within an hour returns the same held restore.
|
Responses
The specification does not describe this response body; the note in the rail says what to expect.
Every non-2xx response is an RFC 7807 problem with a stable
code.
Commonly returned errors
The codes this operation reaches on its own path: the auth stack, its own validation and
ownership checks, and the transport. Not a closed set — a shared code from the
full registry can still surface. Each links to the code’s own page,
the same URL its type dereferences to.