Open APIs in Digital Finance: How to Start Engaging Developers

Application programming interfaces (APIs) can help digital financial services (DFS) providers open key functionalities so that others can build a new generation of financial inclusion services and products. In opening APIs to encourage this type of innovation, however, DFS providers can fall into a “build it and they will come” mindset trap. Yes, DFS APIs can be used to build apps and create new revenue streams, but that doesn’t happen on its own. To entice third-party app developers to innovate with APIs, DFS providers need to provide the right kind of resources.

This doesn’t mean a provider just embarking on its open API journey needs a full-fledged developer portal. As CGAP’s API maturity model primer stresses, opening APIs is an iterative, experimental process. DFS providers are encouraged to release initial API offerings and test them in the market to identify ideal revenue streams and ensure APIs help third-party businesses build new products. Engaging developers is no different. DFS providers should start with a minimum viable product (MVP) — some basic documents that help developers understand the initial API offering. As features are added to the API itself based on feedback from early adopters, additional resources can be offered.

The CGAP API Dashboard identifies the developer resources most commonly offered by leading open API providers in the DFS community. Below, we break down best practices at various stages of the API journey.

Starting the open API journey: reference documentation

When DFS providers first launch APIs, they typically offer a small set of resources to help developers understand the APIs’ functionalities. These resources are often self-serve in nature and provide only the bare bones of what is necessary to start using the APIs. At this stage, the MVP for developer engagement normally includes:

• API reference documentation. This is a series of web pages that list the types of information (“endpoints” in API terms) that third parties can access, or “call,” via the API and what actions can be carried out. For example, a third-party that wants to create an e-commerce app could check reference documentation to see how a DFS provider’s API allows apps to check consenting customers’ account balances before processing a transaction.
• Sandbox environment. After looking through the reference documentation and deciding that a provider’s API meets its need, a third-party developer may want to test the API’s functionalities. A sandbox environment allows developers to test APIs directly in the documentation pages before they sign a partnership agreement.
• Self-serve sign-up. Self-serve sign-up makes it easy for developers to access the sandbox. Developers provide their email address and immediately receive an API key that allows them to use an API when they build an app. Developers often need to submit an application and sign a partnership agreement before they are given production-level access to the APIs.

DFS providers package and share these resources in different ways. Open source payments platform Apache Fineract uses Atlassian Confluence templates — which are like website templates, but in a format already understandable to developers — to explain how their API works. Confluence is a team collaboration product with a monthly fee, but the license allows visitors to view pages without being paid users.

Microlending platform Kiva offers simple reference documentation that lists all its APIs’ endpoints, provides an example of how they are used and explains what response to expect and whether it is being used in the market. The example below describes two API functions: one to retrieve lender details and one to see a particular lender’s loans. An example is provided on how to make the API call, what additional fields (parameters) can be added to filter the API call, how the responses are provided and whether the query is in demonstration or production mode.

The bottom line is that, at a minimum, API providers should offer reference documentation for each of its API’s functionalities detailing how third-party apps can call, or access, the API. Making the documentation visually appealing for developers helps them navigate it and encourages them to use it more frequently.

Midway through the API journey: creating a developer portal

Over time, as more developers start using a provider’s APIs, additional resources will need to be made available. Some DFS providers — like Eko and Safaricom — put all their documentation in one area of their website. Resources made available in this way are usually called a “developer portal.” A mature developer portal often includes:

• Developer portal landing page. This page provides an overview of the business’ API strategy and welcomes the developer on board.
• Online forum. Many DFS providers offer an online support forum where developers can ask questions while other developers read along so they can avoid stumbling on the same integration challenges. Increasingly, new players are creating these forums on Slack.
• Blog. Some DFS providers round out their documentation with additional resources, such as a blog that shares insights from the engineering team. Most API providers documented in the CGAP API Dashboard do not yet offer blogs. Maintaining a blog and encouraging readership is a heavy-resource task, and many providers consider an online forum to be a higher priority.
• Tutorials. In addition to the help-yourself API reference documentation, DFS providers can create step-by-step guides and tutorials that walk developers through using the API in their use cases. For example, Hover provides getting started guides to help developers build applications that use the company’s payments API.

End of the API journey: preparing for commercial success

Developers using an API are businesses. In their eyes, accessing an API is like purchasing a raw product from a supplier so that they can use it to make a consumer-facing product. DFS providers need to recognize this by creating resources to help developers make purchasing decisions. These include:

• Pricing pages. Developers want to know how much it will cost to use APIs so that they can calculate their own pricing and business models. Because many DFS providers are in the early stages of the API maturity cycle, many have not yet announced their pricing. Such a provider should consider a page that explains their expectations for providing free APIs while they work out a monetization strategy, or that invite discussion with developers around revenue-sharing models.

• Status pages. APIs need to be able to respond to calls anytime, day or night (known as “uptime”). If APIs are being used in applications, end users could be using them around the clock. So if the API is slow or not working, the applications using it won’t work. Having an overview of an API’s uptime and current performance levels gives businesses confidence that if they start using an API, it will be reliable and robust enough for them to use to offer products to their customers.
• Changelogs. Given the need for many DFS providers to iterate as they build their APIs, tracking code updates in a changelog page helps communicate any changes to external parties so that they can quickly update their own code, if necessary.

We have provided some examples above, but to get an even better sense of how DFS providers are approaching developer engagement, take a look at players like PayTM, Flutterwave and Africa’s Talking on the CGAP API Dashboard.