Skip to content
Weaver Docs

API And Metrics

Weaver exposes three surfaces. The NZBGet-compatible API is how download-client integrations connect. The GraphQL API is what the web UI uses. The metrics endpoint feeds Prometheus. All three authenticate with API keys.

NZBGet-Compatible API

Section titled “NZBGet-Compatible API”

Weaver answers NZBGet’s JSON-RPC at /jsonrpc and XML-RPC at /xmlrpc, so any client with an NZBGet option works unchanged. Configure the client as NZBGet:

FieldValue
Host and portWeaver’s address, 9090 by default
URL baseThe --base-url prefix, if any
UsernameAnything. It is ignored.
PasswordCreate an API key with scope Control the queue in Weaver under Settings → Security → API Keys, then paste it here.
CategoryA Weaver category name or alias

Scryer, Sonarr, Radarr, Lidarr, and nzb360 have all been exercised against it. The facade covers queue, history, status, append by file or URL, edit queue actions such as pause, resume, delete, priority, and move, post-processing pause and resume, the speed limit, and per-server volumes. Priority, category, and the *Unpack:Password parameter map onto Weaver’s own fields. Methods that would expose configuration, such as config and loadextensions, need Read or Admin scope respectively and return Weaver’s own shape.

For Scryer, add Weaver in Settings → Download Clients as an NZBGet client. In Docker, use the service hostname, such as http://weaver:9090. If you set WEAVER_HTTP_ALLOWED_HOSTS, list that name too. See Reverse Proxy and Storage Layout for the shared mount.

There is no SABnzbd-compatible API.

GraphQL API

Section titled “GraphQL API”

The GraphQL API at /graphql, with subscriptions over WebSocket at /graphql/ws, covers everything the UI does: queue, history, settings, RSS, servers, backups, and system state. Send the API key as a bearer token:

Terminal window
curl -H "Authorization: Bearer $WEAVER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ jobs { id name status } }"}' \
  http://localhost:9090/graphql

The schema is served by the endpoint itself for introspection. Use the narrowest scope that fits: Read for dashboards, Control the queue for submitting jobs, Admin only for automation that changes settings.

Weaver also has a job submission endpoint used by Upload, with WEAVER_NZB_UPLOAD_LIMIT_BYTES and WEAVER_NZB_DECOMPRESSED_LIMIT_BYTES bounding the accepted size.

Metrics

Section titled “Metrics”

/metrics exposes Prometheus metrics and requires a Read API key unless WEAVER_METRICS_AUTH_REQUIRED=0. Scrape it every 30 seconds. Fifteen is the floor.

prometheus.yml
scrape_configs:
  - job_name: weaver
    scrape_interval: 30s
    authorization:
      credentials: <read-scoped API key>
    static_configs:
      - targets: ["weaver:9090"]

What you get:

  • Pipeline gauges for jobs by status, download, decode, commit, and recovery queue depths, active verify, repair, and extract workers, and the write buffer.
  • Throughput counters for bytes and articles downloaded, decoded, and committed, plus retries and articles not found.
  • State sets such as the download gate reason, which reports isp_cap while the cap holds the queue, and per-server state.
  • Per-server series labeled by server_id, with a weaver_server_info series carrying the name.
  • Per-job series for active jobs by default. [metrics] per_job_series = all in Weaver’s TOML config includes finished jobs, and off drops them while keeping the aggregate.
  • Histograms for disk write latency and article fetch timing, and the standard process_* metrics.

The Monitoring page charts the same data in the UI. See Queue And History.

Section titled “Related”