REST caps concurrent requests; tested against RouterOS 7.24.3 RouterOS answers only the first of several requests queued on one HTTP connection, and .NET Framework's HttpClient queues them once two connections are open. History (beta3), REST connection and Threading pages describe the cap; Home and the beta3 verification line name 7.24.3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Threading and concurrency: one page, and a section on every transport page The contract was spread across a subsection of the capability matrix and a paragraph on some of the transport pages, with the rest — Close under a running command, Safe Mode as connection-wide state, the aggregate throughput ceiling — reachable only from the capabilities page. It now has a page of its own, and the capability matrix keeps the two-group table and a pointer to it. Every connection type's page now carries a "Thread safety" section that answers for that transport rather than for transports in general: the CLI pages say what a monitor on the same connection can miss, REST says that the router serves one REST session at a time so a long command blocks the requests behind it, native WinBox says Open is the lockstep exception. API-SSL had no such section at all.