In this blog, Technical Product Manager, Jacob Vincent, answers FAQs about Application Programming Interfaces (APIs), the use and importance of integrations in local flexibility markets, and a sneak preview of how Piclo is spearheading this progress and how Piclo Flex users can get involved.
As electricity grids decarbonise and more network management is needed, local flexibility services in the UK and internationally are scaling and moving towards shorter-term markets. But these developments require a new approach - one that centres on integration and automation.
API stands for Application Programming Interface. APIs define a way for two systems or applications to exchange data with each other. An application can interact with another using APIs just like a human uses a user interface (UI) to interact with an application. In modern software development APIs are ubiquitous: whether you know it or not, you are surrounded by APIs every day.
In broad terms, there are two types of API: private and public. Private APIs are those used only internally to a piece of software. They connect subsystems together like a frontend and a database, and they are not designed to be used from outside of the application. It is likely that every website you access uses private APIs under the hood to dynamically deliver content.
The other type, and focus of this article, is public APIs. Sometimes these are also known as external or partner APIs depending on how they are marketed or consumed. These APIs are exposed to the internet and allow authorised applications to interact with one another in the same way that a human would. Amazon, for example, maintains hundreds of APIs that allow users to develop their own apps to automatically buy and sell from the marketplace or to connect their Amazon operations to 3rd party logistics platforms.
At Piclo, we have many use cases in mind for our users that are interested in integration. Three of our favourites are: removing repetitive human processes; connecting intelligent systems to Piclo; keeping a consistent look and feel across your internal applications.
Firstly, by removing repetitive human processes you can increase productivity. For instance, if a Distribution System Operator (DSO) has received lots of bids from Flexibility Service Providers (FSPs) to provide flexibility services, rather than manually entering every bid decision into Piclo via the UI, a small script could repeat the process for each accepted or rejected bid and send the results by API.
Secondly, connecting systems together adds an extra layer of value. Wouldn’t it be great if FSPs’ Virtual Power Plant software could automatically update Piclo Flex on the availability of their assets, and then the DSO’s DERMS could retrieve that information to augment utilisation decision making?
Third, keeping a consistent look and feel across all of your applications. If you’ve got a set of internal apps for managing your processes and find it a burden to switch over and log in to Piclo Flex, then you could develop your application further and make use of the Piclo Flex APIs to perform the actions you need without users leaving your in house tools. If you are considering purchasing or upgrading systems to manage your assets then it's definitely the right time to consider integrations and what benefits could result from them.
We are building our APIs around three core themes: automation, end-to-end, and flexible. Each one of those provides a unique benefit to our users. Enabling automation is all about improving consistency and saving time. We want our users to be able to perform the right action every time and at the earliest possible opportunity. It’s all about removing barriers to procuring flexibility at the time it is needed.
Our end-to-end vision for APIs is a reflection of our end-to-end vision for the entire platform. On Piclo Flex we are facilitating the entire flexibility journey from competition to settlement, and we plan to unlock all of this by API. Every action a user can take on Piclo Flex manually should have an equivalent via API. Flexibility isn’t just about our commitment to energy flexibility, but it represents our desire to support users getting integrated at their own pace. We’ve designed our systems and APIs without a need to integrate everything in a big bang. We think all our users can get some benefit from integration even by only making use of a single API.
All of this comes together to make flexibility markets more efficient, dynamic, and robust. We envisage a near future where competitions are automatically created when a constraint is forecasted, asset availability is always kept up to date, dispatch instructions are received and acted upon immediately, performance is calculated as soon as possible after the event, and payment is received promptly. In this future, we see people as responsible for overseeing actions and processes where necessary, but not performing the tasks that can be automated themselves. In doing so, this will minimise the risk of human error and free up time and resources for other more important tasks! Being able to react immediately and automatically will move flexibility markets to real-time and enable them to scale efficiently, in turn giving more certainty about the grid constraints, asset availability, and external factors, and ultimately reducing risk and cost.
Above all, we know that our users are ready or will be ready for API integration in the near future because they tell us. For the early adopters, we are taking the journey with them, sharing learnings and improving the proposition. One such test bed for APIs is in the LEO-Transition project where the Neutral Market Facilitator is exploring running competitions in parallel on Piclo Flex to give Flexibility Service Providers more choice about the platforms they choose to use for market access.
So why now and not when all of our users are ready? Simply because once they are ready we don’t want to be a speed bump in transforming their operations. We also want to contribute to the API standards we see evolving. We are committed to openness and interoperability in our APIs, and through our early learnings, we can contribute to the process of standardisation in this area of the industry.
The short answer is “no” to both. APIs are only there to unlock actions already happening manually on Piclo Flex and we’ve got no plans to ditch the web user interface. The web app is a great starting point for those who are new to flex markets or don’t have the resources or systems available to use APIs. APIs alone won’t solve all the challenges facing flexibility markets but can unlock speed and scale that wasn’t previously available.
I mentioned our principle of flexibility earlier and it applies again here. On one hand, giving flexibility to our users with a different way to interact with Piclo Flex, and on the other hand, markets will evolve, behaviours will change, systems will improve, and our APIs will change with them.
There are several ways our users can already start using APIs to interact with Piclo Flex. System Operators can create, manage, and run competitions including making decisions on received bids. Flexibility Service Providers can upload and manage their assets by API. Our API documentation is openly available for free at https://docs.picloflex.com/ so go check it out!
But this is a small part of the bigger picture, we are working behind the scenes to open up the end-to-end Piclo Flex user journey with APIs and you can expect some more exciting news soon.
We are currently looking for more Flexibility Service Providers to join our API pilot, which will extend to include bidding this summer. If you are interested in finding out more or have any questions, feedback or want to discuss how APIs can help you then get in touch with support@picloflex.com.