# Delete an adhoc check

`DELETE /adhoc-checks/{adhoc_check_uuid}`

- Base: `DELETE https://portal.watcheye.com.au/api/v1/adhoc-checks/{adhoc_check_uuid}`

Soft-deletes the adhoc check. For a group check (`check_type = group`), its child checks
are deleted alongside it. See the
[Soft Deletion](/docs/guides/watcheye_api/soft-deletion) section of the API guide
for the full policy (30-day recovery window, portal-only restore).

The records are no longer returned by list/show endpoints but remain in the database for
compliance and audit purposes. The deleted adhoc check record is returned in the response
as confirmation.

## Parameters

| Name | In | Type | Description |
|------|----|------|-------------|
| `adhoc_check_uuid` | path | string (uuid) | **Required.** The adhoc check UUID |

## Responses

### 200 Adhoc check deleted (soft-delete - returned as confirmation)

Content type: `application/json`

| Field | Type | Description |
|-------|------|-------------|
| `data` | object | A one-off "quick check" run from the portal by an account user against a free-form subject, with no associated program or entity record. The base shape is the same on the list and detail endpoints; the detail endpoint additionally embeds the typed `details` block and the uniform `results_overview` and `children` arrays (see AdhocCheckDetail). |
| `data.uuid` | string (uuid) | The adhoc check's UUID Example: `6f9e0a8e-2b9f-4f0e-8d1a-1e2b3c4d5e6f` |
| `data.check_number` | string | A short obfuscated public identifier for the adhoc check (e.g. "Q-A1B2CD") Example: `Q-A1B2CD` |
| `data.check_type` | string | The type of check that was run. One of the supported screening operations (e.g. `pep_sanction_check`, `phone_check`, `business_check`) or `group` for an aggregate record that owns one or more child checks. Example: `pep_sanction_check` |
| `data.check_type_name` | string | Display name for the check type (e.g. "PEP and Sanction Screening", "Phone Check", "Group Check"). Suitable for showing in UIs. Example: `PEP and Sanction Screening` |
| `data.status` | string | Lifecycle status of the adhoc check: * `pending` - the check has been created and charged but the upstream call has not started yet * `processing` - the upstream provider is being called * `complete` - the check finished successfully and `outcome` is populated * `failed` - the check could not be completed; `failed_reason` is populated and the credit charged at launch has been refunded For group adhoc checks the status is rolled up from the children: any child still pending or processing keeps the group at `processing`; the group is `failed` when any child failed, otherwise `complete` when every child is complete. Enum: `pending`, `processing`, `complete`, `failed` Example: `complete` |
| `data.failed_reason` | string or null | Short reason why the check failed. Populated only when `status = failed`, otherwise `null`. |
| `data.outcome` | string or null | High-level outcome of the check: * `pass` - nothing flagged * `warning` - one or more matches found that you should review `null` for group checks that have no child results yet, and for checks that have not reached `status = complete`. Enum: `pass`, `warning` Example: `warning` |
| `data.check_summary` | string or null | Short, human-readable summary of the result (e.g. "Found 2 PEP matches", "All phones connected", "Business record exists"). `null` if the operation did not produce a summary. Example: `Found 2 PEP matches` |
| `data.data_summary` | string or null | Short, human-readable summary of the subject the check ran against (e.g. "John A Smith, 1980-06-23" or "ACME Pty Ltd, ABN: 12 345 678 901"). For adhoc checks the value is captured at run time from the data the user typed into the quick-check form. `null` for group checks and for checks whose operation did not produce a subject summary. Example: `John A Smith, 1980-06-23` |
| `data.checked_at` | string (date-time) or null | ISO 8601 timestamp at which the check was run. `null` while the check is still `pending` or `processing`. Example: `2025-01-01T00:00:00Z` |
| `data.created_by` | object or null | Identifies who launched the adhoc check. The `type` discriminator picks the shape of the remaining fields: * `{ type: "user", uuid, username }` - a portal user launched the adhoc check. * `{ type: "api_key", uuid, label }` - an API key on this account launched the adhoc check. * `null` - rare legacy rows from before actor attribution was recorded. If the user has since been deleted from the account the historical record is retained and the original `user` discriminator is still returned. |
| `data.created_by.type` | string | Discriminator for the actor type. Enum: `user`, `api_key` |
| `data.created_by.uuid` | string (uuid) | UUID of the user or API key that launched the check. |
| `data.created_by.username` | string | Username of the portal user. Present only when `type` is `user`. |
| `data.created_by.label` | string | Label of the API key. Present only when `type` is `api_key`. |
| `data.parent_uuid` | string (uuid) or null | UUID of the parent (group) adhoc check this check is a child of. `null` when the check is not part of a group. |
| `api_reference` | string (uuid) |  |

**Sample response**

```json
{
    "data": {
        "uuid": "6f9e0a8e-2b9f-4f0e-8d1a-1e2b3c4d5e6f",
        "check_number": "Q-A1B2CD",
        "check_type": "pep_sanction_check",
        "check_type_name": "PEP and Sanction Screening",
        "status": "complete",
        "failed_reason": null,
        "outcome": "warning",
        "check_summary": "Found 2 PEP matches",
        "data_summary": "John A Smith, 1980-06-23",
        "checked_at": "2025-01-01T00:00:00Z",
        "created_by": {
            "type": "user",
            "uuid": "00000000-0000-0000-0000-000000000000",
            "username": "string",
            "label": "string"
        },
        "parent_uuid": null
    },
    "api_reference": "00000000-0000-0000-0000-000000000000"
}
```

Standard error responses: 400, 401, 403, 404, 429, 5XX (see [Common error responses](/docs/reference/general/common-error-responses.md))