5 Keys to Addressing the Needs of API Consumers

Open application programming interfaces (APIs) could play a key role in unlocking innovation in digital financial services ecosystems and expanding low-income people’s access to financial services. However, not all APIs are created equal. APIs that are designed to meet the needs of third parties can have an enormous impact in the way the developer community can experiment, learn and ultimately consume APIs in a range of applications. But APIs that do not take the needs of third parties into account can end up being cumbersome, costly and ultimately inadequate. So how can API providers design better APIs?

Man on computer, Zimbabwe

In 2016, CGAP conducted interviews with companies from different industries and at different levels of maturity (e.g. startups vs. established players) in East Africa who had either integrated with APIs or were in the process of doing so. The purpose of these discussions was to identify the key issues third parties faced when trying to consume available APIs and to think through potential solutions to these challenges. The following subset of recommendations for digital payment providers looking to open APIs flows directly from the main issues third parties were facing.

Set up a dedicated, well-resourced API team

Designing, launching and managing an API requires a dedicated, well-resourced API team. Think of an API as a new product targeting a new customer segment. Launching the product is only the start. Over time, the team will need to ensure that it monitors the use of the product, markets its product by engaging the developer community, updates and enhances the product in response to user feedback, continues to deliver a great user experience, provides access to the required support, and more. Otherwise, the API will remain static and likely fall out of use with customers.

Consult third party application developers early and often

Local and international application developers are the key customers of APIs. Providers should engage them throughout the API design and implementation process. They can help avoid pitfalls and anticipate needs, including the precise APIs they want and will use. Third party application developers can even contribute to an API’s functionality by writing software development kits for multiple programming languages, making the API even more accessible to potential users (see fintech startup Plaid’s community libraries, for example).

Use web service API best practices and standards

Third party application developers expect to be able to integrate with a web service API using standard web service methods and protocols (e.g., REST vs. SOAP, JSON vs. XML, OAuth and SSL/TLS vs. VPN). When non-standard methods and protocols are used, the cost and time required to integrate with an API can increase dramatically. Startups in particular can be disadvantaged — if not precluded entirely — when API providers choose complex, non-standard methods and protocols. GSMA is working on a harmonized set of mobile money APIs to leverage best practices from the technology industry.

Create a do-it-yourself developer portal for third party developers

API providers should consider building an API dashboard for third party application developers (for example, Stripe’s developer dashboard). This dashboard should include API reference documentation, access to API keys, access to a sandbox with test data, and access to additional reference materials. By offering a portal for developers, API providers can significantly reduce the strain on their API and customer support teams, which might otherwise get overwhelmed in the absence of an API dashboard. For third parties, a self-service portal can reduce the time to connect and enable an experience where they can quickly test and iterate their innovative solutions.

Design APIs to accommodate failure and provide recourse

Digital payment providers’ systems periodically fail, whether as a result of communications networks going down or other platform-related issues. Creating APIs that accommodate such failures is important for third party application developers. It enables them to continue to serve customers and seamlessly reconcile these problematic transactions after the fact, avoiding burdensome reconciliation processes and missing payments.

As digital payments providers continue the transition to openness, it is our hope that they will consider these recommendations to address some of the main issues third parties typically experience.