Control Automations from Any Application
Use authenticated API calls to start, stop, and check the status of local workflows.
Beyond the Desktop Interface
The desktop interface is convenient when you are at your computer, but many production workflows are triggered by other systems. A spreadsheet script may need to start a scrape after new data is entered. A monitoring tool may need to confirm that a scheduled workflow is still running. An internal dashboard may want to show the latest run status.
API triggers give those systems a clean way to interact with RTILA X. Because the API runs locally, there is no cloud account or hosted execution server involved. The application listens for authenticated requests and executes the mapped workflow.
Starting and Stopping Workflows
API endpoints can start a project, pause a running workflow, resume a paused run, or stop a workflow cleanly. Each action requires a valid token and the project identifier. When a request arrives, RTILA X performs the action on the local machine and returns confirmation or an error message.
This makes it easy to integrate RTILA X into larger internal tooling. A CI/CD pipeline could start a data refresh after deployment. A scheduling script outside the app could trigger a one-off scrape during an overnight job.
Querying Run Status
In addition to control actions, the remote API provides status queries. You can ask which projects are running, how far a workflow has progressed, and what the most recent run reported. These endpoints are useful for dashboards, monitoring systems, and simple team tools that need awareness without opening the desktop app.
Status responses include checkpoint position, last completed command, and any recent errors. This gives external systems enough detail to decide whether a workflow needs attention.
Securing API Access
Because the API can control automation on your machine, access must be protected. RTILA X issues local tokens that you manage in the remote execution settings. You can regenerate tokens, restrict which projects are exposed, and monitor incoming requests through the logs.
The API is optional and disabled by default. Most users never need it, but for teams that want tight integration with custom tooling, it provides the local control layer they need.