By Mark McCann and John Greenhow, Tecassa
While they began as something only relevant in the technical domain when integrating software systems, Application Programming Interfaces, or APIs, are now seen as products in their own right.
An API is used to enable pre-programmed interaction between two systems. We see APIs used for trading, account opening, accessing client or market data and other functions that link systems together to provide greater efficiencies and a smoother experience for end clients.
The modern API is not just an interface between software systems, but between businesses, and a fundamental building block of the digital economy. By treating APIs as products, businesses can unlock their potential for generating revenue, enabling innovation, and driving expansion.
What makes an API a product?
In order for a suite of APIs to be considered a product, they must possess several essential elements.
- A monetisation strategy that aligns with the client’s needs
This will ensure that the API pricing is perceived as fair and justified by the revenue they support, typically within the broader context of the business supported by the API.
- The developer experience
Providing comprehensive documentation, robust support, and user-friendly endpoints to client’s developers reduces the overall cost to both parties, reduces time-to-market and encourages onboarding.
- Marketing
As with any product, targeted promotion helps drive adoption. Well-presented API home pages and demonstration sites are crucial to impress the eyeballs brought by marketing.
- Ongoing management
As needs evolve, it’s important to act on feedback to foster continuous improvement, optimising usability, and effectiveness. This necessitates careful versioning and maintenance to build trust and provide clients with a clear vision for anticipating changes.
Looking from the outside in
Developing APIs as products requires a shift in mindset from an “inside-out” approach to an “outside-in” approach.
An inside-out approach focuses on taking the interfaces in existing systems and re-packaging them as the public interface. This can result in APIs that are tied to internal architectures and may lack the flexibility to meet client needs. It may be more costly to change in response to client feedback, as it may involve more systems than just the API.
On the other hand, the outside-in approach begins by understanding the needs of the clients who will use the API – their pain points, requirements, and expectations – to create APIs that are easy to use, intuitive, and solve real-world problems.
Adopting the outside-in approach helps companies create API products that clients find useful, ultimately increasing adoption rates, in turn driving a customer-centric culture of innovation and continuous improvement. It positions APIs as strategic assets that contribute to the overall success and competitiveness of a business in the digital landscape.
A worked example
Let’s examine the difference between inside-out and outside-in thinking through the lens of an API designed for portfolio management.
In an inside-out approach, the broker might develop the API to match their existing portfolio management system. They would focus on exposing the functionalities and data fields that replicate the current system’s capabilities and their in-house processes. This API might include endpoints for retrieving balances, updating distributions, and requesting performance reports. The primary goal would be to digitise the existing steps by which clients interact with the broker.
In contrast, an outside-in approach would begin by understanding the client’s needs and objectives, seeking input on pain points and how their processes work, and how managing portfolios could be best supported by an API. In this case, the broker might prioritise additional features useful to clients that aren’t in the underlying back-office – e.g., consolidated views for online display or real-time analytics, in addition to the existing functions.
An outside-in implementation must also prioritise features such as clear and comprehensive documentation, intuitive endpoints, and error-handling mechanisms, making it easier for client’s developers. Additionally, the API might offer optional features or customisation options to cater to the needs of many different clients and their applications.
The outside-in approach also considers broader ecosystem factors, such as regulatory compliance requirements, industry standards, and use of (or not) emerging technologies. By taking a holistic view, the broker can design an API that meets the technical requirements, delivers value, and fosters greater collaboration with external developers and partners.
Embracing this API-as-a-product model with an outside-in mindset offers a transformative approach to API development. This approach prioritises clients’ needs in order to drive innovation and value creation. By shifting focus from internal architectures to the needs of end users, companies can unlock new opportunities for collaboration, growth, and differentiation.
Tecassa provides cutting edge technology solutions and advice to financial markets participants – from pricing and algos to APIs and subledgers. Contact the team to talk through your next steps with technology.
This article is general information and does not consider the circumstances of any investor or constitute advice. Material published in SIAA Newsroom is copyright and may not be reproduced without permission. Any requests for reproduction will be referred to the contributor for permission.
