API

Inspectarr exposes a small read-and-trigger JSON API for external integrations — dashboards, monitoring, and automation. It is not a full management API; anything destructive still happens through the UI or the scan pipeline.

All endpoints return JSON. When authentication is enabled, every endpoint requires HTTP basic auth except /api/health, which is exempt so container healthchecks can reach it without credentials.

---

GET /api/health

Liveness and readiness. Reports Inspectarr's own health — the process, its database, and its scheduler thread.

Makes no outbound network calls, so it is safe to poll frequently. This is what the Docker HEALTHCHECK uses.

{
  "status": "healthy",
  "version": "1.6.0",
  "checks": { "database": "ok", "scheduler": "running" },
  "last_scan": "2026-08-22T18:53:13.617482+00:00"
}

Field	Values
status	healthy · unhealthy
checks.database	ok · error · unavailable
checks.scheduler	running · scanning · stopped · died · unavailable

Returns 200 when healthy, 503 when a core component has failed.

scheduler: stopped is healthy. The scheduler ships disabled and webhook-only deployments never start it. The unhealthy scheduler state is died — the flag claims it is running but the thread is gone.

GET /api/health?deps=1

Additionally checks every configured service (torrent client, Sonarr, Radarr, Lidarr, Prowlarr, Ollama), concurrently.

This variant makes outbound calls, is slow when a service is unreachable, and requires authentication. Do not use it in a healthcheck — a probe that fails because Sonarr is down would restart a perfectly healthy container.

{
  "status": "healthy",
  "dependencies": [
    { "name": "Torrent Client (qbittorrent)", "configured": true, "ok": true },
    { "name": "Sonarr", "configured": true, "ok": true },
    { "name": "Lidarr", "configured": false, "ok": false }
  ]
}

configured: false means the service is disabled in config, not that it failed.

---

GET /api/status

Scheduler state, last run, and a high-level config summary.

{
  "ok": true,
  "scheduler": {
    "running": true,
    "interval_seconds": 300,
    "polling_enabled": true,
    "webhooks_enabled": false
  },
  "config": {
    "torrent_client": "qbittorrent",
    "dry_run": false,
    "rules_count": 2,
    "prowlarr_enabled": true,
    "notifications_enabled": true
  },
  "last_run": { "...": "most recent run_history row" }
}

---

POST /api/scan

Triggers a scan. Returns immediately — the scan runs in the background.

curl -X POST http://inspectarr:8585/api/scan

{ "ok": true, "message": "Scan triggered" }

Returns ok: false if a scan is already in flight.

---

GET /api/logs

Recent entries from the JSON Lines event log.

Parameter	Default	Purpose
level	all	Filter by DEBUG · INFO · WARNING · ERROR · ACTION · DRY_RUN
limit	100	Maximum entries (capped at 500)

curl 'http://inspectarr:8585/api/logs?level=ACTION&limit=20'

Entries carry an inspection_id where one applies, so every event belonging to a single catch can be correlated — see Detection & Actions.

---

Example: external monitoring

# Alert if Inspectarr is unhealthy
curl -fsS http://inspectarr:8585/api/health >/dev/null || notify "Inspectarr unhealthy"

# Alert if nothing has scanned in 6 hours
curl -s http://inspectarr:8585/api/status \
  | jq -r '.last_run.scan_end'

---

Related

• CLI Usage — the same operations from a shell
• Authentication — protecting these endpoints