Using application program interfaces – or APIs – in robotic process automation (RPA) is an interesting and often divisive issue. After all, RPA is all about mimicking the interactions of the human workforce, right? If we use APIs, then we are moving away from the whole point of RPA, aren’t we?

There is no easy answer to this and no definitive best practice. While APIs have a place in RPA, make sure they don’t have too much of a home in your capability.

Let’s set the scene

As you’ll know, APIs simplify interactions within an application by operating ‘behind the scenes’ – bypassing traditional user-based interfaces and only exposing or accessing what’s necessary for the operation to take place in a fast and efficient code based way.

Robotic process automation platforms like Blue Prism or UiPath are there for the business. Let IT create the governance and controls around the platform – the padded room so to speak – then let the business teams automate within that using a no-code solution (using the existing human user controls of the application). Responding to their own business needs far quicker than traditional IT approaches.

RPA is no silver bullet but it is very good at what it does, providing the organisation really understands what it is and how it should be used. Scalable, compliant, secure and robust: those are the fundamental principles of any capability we help to establish.

No alt text provided for this image

When not to use APIs

To understand where APIs fit in, I’ll first outline the key arguments against there use in RPA.

The use of APIs undermines RPA business continuity plans. If your robots go offline for whatever reason, how will the business perform the tasks manually again if they are using APIs? Most RPA platforms allow us to step through individual parts of a process, i.e. click a link, enter in text, click a button. That is what’s typically recorded in the process definition documents created during the analysis stages.

No alt text provided for this image

At each stage we can see what the robot is doing, confirm, redo, adjust. We get minute control over the robot’s activity, and a user can step through these actions manually if needed. APIs don’t generally allow for this; it’s a black box – send some inputs, wait for the outputs/results. This limits us to how we can build, debug, test, and live prove in RPA.

APIs are consumed by code. You’ll need skill sets to build the code and support it long-term. Suddenly your code-free platform is not looking so code-free. Building and testing can take longer and also, fixing any production issues can be more complicated and take longer to resolve. Further, the misuse of APIs can impact performance on the application they interface with, far more than automating using the applications’ user interface (UI).

When to use APIs

That all said, there are still some specific use cases where APIs are a better option for automating.

APIs are great for automating third party applications where there is no visibility or control over UI changes; for automating applications that are under constant change or in development; and for automating applications that have inconsistent or buggy interfaces, or interfaces where modelling can prove difficult for other reasons. Bypassing much of the UI can make for a cleaner process – and when processing speed is critical, using APIs can also speed up your process. It can seem like an attractive proposition across the board.

There are also situations where APIs are the only viable option, like consuming AI engines or even RPA supporting software like CyberArk or ABBYY.

No alt text provided for this image

Other considerations 

There are some other things to keep in mind with APIs and RPA.

APIs often don’t have all the functions or validations that the application front-end has, potentially limiting the effectiveness of their use. Take ABBYY for example. The RPA connector (API) doesn’t have the ability to extract multiple documents from a single image file while it’s easily possible through the standard functionality. 

While users understand their applications, they won’t understand the data that an API will return, so there is an associated learning curve your RPA team will need to travel to understand the API fully. Some RPA platforms are more API friendly; some make them easier to consume, and some RPA platforms naturally rely on APIs more than others.APIs will to be crucial to the digital workforce of the future, the one where RPA is central to that worker but relies on cognitive functions and other abilities consumed via APIs. Consider the potential, and don’t lock yourself out of this emerging trend.

There are valid use cases for consuming APIs and those use cases will only increase in the future. What is best for a capability, and how limited their use should be, really depends on how and why an organisation is using RPA strategically. Technical leaders need to carefully weigh up the pros and cons and make the decision that is best for their organisation now but with an eye for the future.

My view

As a general rule, I believe the use of APIs should be restricted and only used when modelling the UI is impossible or not feasible. If you rely heavily on APIs, the business loses too much control, and risks/costs can be far higher. If you are only reading data using APIs, then the risks and impacts reduce, but it should still only be used when it makes sense to. 

Try not to give developers the ability to choose if or when to use them without some governance. For instance, you can make it an exception process where they must justify the use of an API (to an RPA design authority) before doing so. Developers often choose the path of least resistance, which can lead to an overuse of – or overreliance on – APIs. This can lead to another layer of code-based integration within the organisation, and it will likely stop you from scaling your capability in the future as you struggle to support and maintain that code in a reusable, robust, secure and compliant manner.