RouterOS automation needs guardrails
Many small ISPs use MikroTik RouterOS for subscriber access, queues, DHCP, firewall rules, PPPoE, routing, and operational troubleshooting. ISPAgents should connect to RouterOS API with preview, approval, execution, and evidence instead of uncontrolled scripts.
RouterOS API workflows
| Workflow | ISPAgents role | |---|---| | Suspend | Apply the correct queue, address list, firewall, or policy action for overdue customers. | | Restore | Restore service after payment evidence is confirmed. | | Plan change | Move speed, shaping, queue, or policy based on the customer service package. | | Support context | Show router state beside billing, RADIUS, CPE, and ticket history. | | Audit | Record before and after evidence, operator approval, command result, and recovery notes. |
When direct API control is useful
Direct MikroTik control is useful when the ISP already uses router-local queues or address lists, when RADIUS is not fully deployed, or when a custom site layout requires exact RouterOS actions.
FAQ
Can RouterOS API and RADIUS coexist?
Yes. Some workflows belong in RADIUS, while others may need direct RouterOS API action. ISPAgents should support both according to the network design.
Should all commands run automatically?
No. High-risk actions should require preview, approval, and rollback evidence before execution.