Using APIs in Robotic Process Automation
Using APIs in 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, right?
There is no easy answer to this and no definitive best practice. APIs have a place in RPA; just make sure they don’t have too much of a place.
Let's set the scene
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 integrated teams automate within that using a no code solution, 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 key principles of any capability we try to establish.
Why not to use APIs
To understand where APIs fit in, lets outline why they shouldn’t be used.
- Use of APIs undermines business continuity plans. If your robots go offline for whatever reason, how will the business perform the tasks manually again if we are using APIs?
- Most RPA platforms allow us to step through individual parts of a process, i.e. click link, enter in text, click button. At each stage we can see what the robot is doing, confirm, redo, adjust. We get minute control over what the robot is doing. 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 and debug, test and also how we can live prove.
- APIs are 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 but also, fixing any production issues can be more complicated and take longer to resolve.
- Use 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.
- 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.
- For automating applications that have inconsistent or buggy interfaces, or interfaces where modelling can prove difficult for other reasons.
- When processing speed is critical, using APIs can speed up your process.
- When APIs are the only option. Some applications are only available via APIs, e.g. AI engines or even CyberArk.
Some other things to keep in mind...
- APIs often don't have all the functions or validations that the application front end has.
- Some RPA platforms are more API friendly; some make them easier to consume.
- Some RPA platforms 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. Don't lock yourself out of this emerging trend.
So what should we do?
The use of APIs in RPA is important. There are valid use cases for consuming APIs and those use cases will only increase in the future. What’s 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 at that point in time.
As a general rule, I believe use of APIs should be restricted and only used when modelling the UI is impossible or not feasible. Also, don’t give developers the ability to choose if they can use them or not, make it an exception process that they must justify use of an API before doing so.
Developers often choose the path of least resistance which can lead to overuse of APIs. This can lead to another layer of code based integration, and it will likely stop you scaling your capability in the future as you struggle to support and maintain that code in a secure and compliant manner.