The forty endpoints behind the management console verifiedimportantWritten by the Hub
Everything the REST API cannot do is done by the console over its own HTTP interface — which our own code can use as well.
In detail
The console is a static page that talks to the engine over about forty small endpoints, one per entity. They are not the /v1 API: they live at the root (/capacity, not /v1/capacity), they take ordinary form encoding rather than JSON, and they authorise by the session cookie obtained from POST /login with the www-auth credentials. This matters because the gap in the REST API — no throttles, no rules, no DKIM keys, no rewrite rules, no response patterns — is exactly the set of things the console API covers. On the stand we created throttle profiles, throttle rules, suppressions and pools through it, and every write landed in the database and took effect. So a control module has three roads to a node, not two: the documented REST API for the six entities it covers, the console's own API for everything else, and direct writes to the cluster database followed by a reload. The middle road keeps the engine's own validation and its "stolen" semantics; the last road bypasses both. The console API also answers the ownership questions in a way the database does not: creating a throttle rule that already exists returns {"result": "stolen", "from": 1} rather than silently moving the row.