Why We Built the Control Room API

A little backstory

The Robocorp ecosystem allows our customers to automate almost anything, from old Java applications running on outdated hardware to cutting-edge React apps using our native Playwright integration.

However, we realized that there was one thing our customers could not automate easily: the Control Room itself.

Until now, most interactions with the Control Room have been UI-driven, requiring manual clicks and inputs. And while we do have APIs for processes and robots (now deprecated, discontinued in January 2025), they only cover a subset of features.

We wanted to change that.

We wanted to allow our customers the ability to automate the automation platform, set up and configure their resources, monitor and control their executions, and access their data and insights, all through code.

We wanted to enable our customers to use the same tools and practices we love using internally for managing our infrastructure, such as Terraform, Git, and CI/CD pipelines.

The “Control Room API”

We are big advocates of great developer experience. And we didn’t want it to be an afterthought.

So when we set out to designing the API, we kept our engineers’ hats on and looked at what a good API looks like.

We took inspiration from various APIs (Stripe, Pipedrive…) and reflected on what we think makes a good API.

In our mind, a good API means:

• Consistency: when two endpoints reference the same data, they should use consistent names for that data
• Ease of use: endpoints should require only the essential information to return the data and provide additional useful information, like related resource IDs.
• Proper naming: one of the hardest challenges in programming!
• Useful error messages: when the API returns an error message, it’s our responsibility to guide our customers on how to avoid encountering the error.
• Meaningful descriptions: clearly define which actions are possible, which are not, the significance of specific fields, and whether they are mandatory, essential, or optional.
• Customer-centric: the endpoints should be designed around customer needs, not engineering needs. We should bend our system to please our customers, not bend our customers to please our systems.

Because, truth be told, the API of a company often serves as the company’s “business card” for developers. We want to create a business card so good that our customers frame it when they come home (OK, maybe not, but you get the point, that one business card that you kept because it’s cool and stands out).

“Alright, I get it, your goal is to build the world’s finest API”

Our goal is to deliver the best possible API, acknowledging that it may not be 100% perfect. We’ve already had to make certain decisions to enhance usability, such as prioritizing customer experience over strictly adhering to REST principles.

This might upset some developers, while others may see it as a positive choice. Regardless, we put in our best effort and genuinely hope that the majority of our customers will be excited and happy to use the API.

The API is out

We’re rolling out 60’ish endpoints as part of the first batch and we’ll be actively rolling out new endpoints.

You can already create and manage your assets, workers, webhooks and you’ll soon be able to retrieve and create processes and list process schedules…

If you haven’t had the chance to explore the API yet, we strongly suggest visiting Control Room and playing with the API helper – it can run the queries directly from Control Room!

If you were planning on reading the API documentation with a nice coffee or orange juice on a Sunday (right?), we’ve got you covered: https://robocorp.com/api

If you missed the release note, head over here.

If you feel this blog post lacked AI content, meet ReMark: our AI assistant that will answer any questions you have about the API, or the Robocorp documentation or how to write Python code. ReMark is great, and it’s free.

The Robocorp Platform Team