keenetic-rci

Reaching the Keenetic API directly

The curated tools cover the common questions. rci_call covers everything else. It is deliberately unrestricted, so the responsibility for calling it well is yours.

What RCI actually is

Not REST. It is a JSON mirror of the router's command-line tree, so a URL path is a path through that tree. There are two branches:

Form	What it gives you
GET show/...	operational state, the equivalent of a show command
GET <config path>	the running configuration, as JSON
POST with a body	executes a command; the body mirrors the same tree

GET with an empty path returns the entire running configuration, about 35 KB.

Find the syntax instead of guessing it

This is the single most useful technique. The router stores its own configuration as valid CLI, so it will tell you the exact syntax of anything it is already doing:

rci_call { "method": "GET", "path": "show/running-config" }

Read the lines around whatever you want to change. A host with a routing policy appears as host <mac> policy Policy0, which maps to {"ip":{"hotspot":{"host":{"mac":"...","policy":"Policy0"}}}}. Guessing field names instead produces silent no-ops, described below.

Deleting something: no goes beside the arguments

The negation is not a wrapper key. The router shows an already-negated line as "no": true sitting next to that line's arguments, and a delete is written the same way round. The object's own name travels in name:

{"ip": {"policy": {"no": true, "name": "Policy1"}}}
{"interface": {"no": true, "name": "Wireguard1"}}
{"ip": {"name-server": {"no": true, "address": "1.1.1.1", "domain": "", "interface": "Wireguard1"}}}

A successful delete answers with a status block that names what went, for example removed policy "Policy1". or interface "Wireguard1" removed.. No such block means nothing happened, whatever the HTTP code said.

References clean up on their own: removing Wireguard1 also dropped the no permit global Wireguard1 line that Policy0 still carried.