technitium 0.4.0

# Delete Log

## Endpoint

`/api/logs/delete`

**Obsolete Path:** `/api/deleteLog`

## Method

GET

## Description

Permanently deletes a single log file from the DNS server's disk.

## Authentication

Required. A valid session `token` from `login` or `createToken`.

**Permission:** Logs: Delete

## Parameters

| Name | Type | Required | Conditional | Description |
|------|------|----------|-------------|-------------|
| `token` | string | Yes | No | Session token generated by `login` or `createToken`. |
| `node` | string | No | No | The node domain name to target. Only usable when Clustering is initialized. When unspecified, the current node is used. |
| `log` | string | Yes | No | The log file name as returned by the List Logs API (`response.logFiles[].fileName`). |

## Response Fields

| Field | Type | Description |
|-------|------|-------------|
| `status` | string | `"ok"` on success. |
| `response` | object | Empty object `{}` on success. |

## Conditional Logic Notes

- The `node` parameter is only meaningful when Clustering is initialized.
- This is a **destructive** operation -- the log file is permanently deleted from disk and cannot be recovered.
- Note that this endpoint uses the parameter name `log`, **not** `fileName` (which is what the List Logs and Download Log endpoints use). This naming inconsistency must be handled in client code.

## Edge Cases

- The parameter is named `log` rather than `fileName`, which is inconsistent with the Download Log endpoint that uses `fileName`. Callers must use the correct parameter name for each endpoint.
- Attempting to delete a log file that does not exist is not explicitly documented; the server may return an error or silently succeed.
- The deletion is permanent and immediate -- there is no soft-delete or confirmation mechanism.
- The response body is an empty object on success, so there is no confirmation data beyond the `"ok"` status.