API and compatibility

Compatibility

Connecting

The API listens on the web interface's port, 6789 by default, at three paths:

Send credentials with HTTP basic authentication, or as the first part of the path, as in http://host:6789/user:pass/jsonrpc. Three accounts set what a client may do:

JSON-RPC takes positional parameters only: names are ignored, and the order matters. Send every required parameter; a method's optional trailing parameters may be left out. Integers wider than 32 bits are split into Lo and Hi fields, such as FileSizeLo and FileSizeHi.

Methods

This is every method that RustyGet answers. All but appendfleet are inherited from NZBGet, and the repository's API reference documents most of them in detail.

appendfleet

appendfleet adds every copy of one release in a single call. RustyGet checks each copy on your news servers, queues the best, and keeps the rest as backups. Duplicate fleets explains how it ranks them.

appendfleet(DupeKey, Category, Priority, Timeout, Name1, Content1, Name2, Content2, ...)

Up to 50 members. Call it over JSON-RPC with POST. XML-RPC callers get an error, and JSON-P, like any GET, can't call it.

The result:

{
  "Chosen": 4182,
  "Complete": true,
  "Reason": "",
  "Members": [
    { "NZBID": 4182, "Name": "Release.Name [copy 01].nzb", "Rank": 1, "Alive": 99, "Status": "QUEUED", "SameAs": 0, "SameAsRank": 0, "Reason": "" },
    { "NZBID": 4183, "Name": "Release.Name [copy 02].nzb", "Rank": 2, "Alive": 97, "Status": "BACKUP", "SameAs": 0, "SameAsRank": 0, "Reason": "" },
    { "NZBID": 0, "Name": "Release.Name [copy 03].nzb", "Rank": 3, "Alive": 99, "Status": "SAME_POSTING", "SameAs": 4182, "SameAsRank": 1, "Reason": "" }
  ]
}

New fields and parameters

listgroups and history items have these extra fields:

The listgroups status and the postqueue stage can be STREAM_REPAIRING.

RustyGet also stores its findings as NZB parameters, which the API returns in Parameters and extensions see as NZBPR_ variables:

Changes to existing methods

RustyGet fixes several problems in NZBGet's API. Clients that rely on the old behavior may need changes:

• JSON-P off by default. Any web page can make a browser send a JSON-P request, with the login the browser keeps, and read the answer. RustyGet answers JSON-P only with option JsonP=yes, and then with the restricted user's access, so user names, passwords, and API keys come back as ***. Otherwise every JSON-P request answers error 403. NZBGet answered JSON-P with full access.
• POST for methods that change something. Plain GET and JSON-P run only the methods that read: config, configtemplates, dump, history, listfiles, listgroups, loadconfig, loadextensions, loadlog, log, logscript, logupdate, postqueue, servervolumes, status, sysinfo, systemhealth, urlqueue, and version. Every other method answers error 4 there. downloadextension, updateextension, deleteextension, testextension, readurl, testserverspeed, testdiskspeed, and testnetworkspeed joined the methods that need POST. In NZBGet, JSON-P ran every method, so a <script> tag on any web page could edit the queue, change settings, or shut NZBGet down with the browser's saved login.
• Access checks in multicalls. The XML-RPC system.multicall method runs each call with the caller's access level. In NZBGet, a restricted account could read passwords through it.
• Range checks. Integers outside the 32-bit range are rejected instead of wrapping around. editqueue checks scores, priorities, parameters, and duplicate modes.
• Safe configuration saves. saveconfig refuses an empty or malformed option list instead of truncating the file.
• Decoding. append decodes post-processing parameters, so passwords with quotes work. Numeric escapes decode to UTF-8, and characters outside the Basic Multilingual Plane come out as valid JSON.
• Correct output. Request IDs are echoed in full, servervolumes returns valid JSON, and resetservervolume persists the reset.