4 Keys to a Successful Developer Portal for Digital Finance APIs

For digital financial services (DFS) providers, open APIs represent a new way of working with customers and partners. Open APIs offer wide-ranging possibilities for third-party businesses to create digital products and services that leverage providers’ capabilities. Open APIs enable providers to extend their market reach and expand the range of products in the marketplace, thus giving customers more reasons to use their accounts. So how can DFS providers make it as easy as possible for partners to start using their open APIs? This is where a developer portal comes into play.

A developer portal is a set of web pages on a DFS provider’s website aimed at meeting the needs of businesses and developers that may use the provider’s APIs. The purpose of the developer portal is to help business leaders understand the value offered by the APIs and to provide the resources developer teams need to start using them. A developer portal must achieve four objectives to help external business partners along in their journey:

1. Drive awareness and understanding. Investing in search engine optimization and listing APIs (with a link to a portal) on catalog sites like Rakuten RapidAPI and ProgrammableWeb can help ensure a steady stream of portal visitors. The portal should immediately make it clear to business audiences, in nontechnical terms, what the DFS provider's APIs do and what business opportunities they offer. Interested business partners will often refer their engineering teams to the developer portal. These developers will need to be able to review information on the portal to gauge how complex it will be to integrate with the provider's APIs.
    
2. Enable exploration. After an initial review, a potential partner will often want to experiment with integrating a DFS provider's APIs. This will involve reading documentation and reference guides that explain each API endpoint. Sample log-in details should allow developers to test APIs in a development or staging environment, often called a “sandbox.” Software development kits (SDKs) and sample code, written in the developer community’s preferred coding language, can speed up the experimentation process. These resources can also help a potential partner decide whether to pursue a formal business relationship with a DFS provider.
    
3. Simplify onboarding. If the partner decides to use a DFS provider's APIs, it should be able to find resources in the developer portal that help them build commercial products. For example, it may want to review terms of service and determine ongoing costs using an API pricing page. Third-party partners may also need to reach out to a DFS provider’s API team with questions about their integration needs and to understand how to authenticate an API.
    
4. Increase engagement. Once a partner has built an API-based product, it may want to market the product to the DFS provider’s customer base. Some DFS providers employ co-marketing strategies, such as showcasing third-party products on their blogs or on marketplace pages within their developer portals. Third-party API consumers will also want to ensure the API is performing and has a stable uptime, and they will want to know how to reach to the provider immediately if the integration goes offline.

Nigerian payments provider Paystack offers a good example of how to achieve these objectives. Its developer portal demonstrates many best practices that other DFS providers can follow. 

When visitors arrive at Paystack’s developer portal, they quickly see:

• The potential benefits and uses of the API
• How to start using the API with a “getting started” guide
• SDKs and code samples in the developer’s preferred programming language
• Documentation that explains each API endpoint and how to make calls
• A sandbox or interactive environment to make test API calls

From here, Paystack goes further and provides developer assets to help developers start building with its API, including:

• A support forum where developers can ask questions
• Examples of applications with the full code, demonstrating what can be built with the API
• A blog with important news and product roadmap updates that create a sense of community
• Terms of service to explain developer rights and responsibilities

For third-party developers who are ready to commercialize their own apps and products built using the API, Paystack provides:

• Detailed use case descriptions that help visitors imagine the products they could build
• A status page showing the uptime and reliability of the API
• API pricing details
• Opportunities to promote products

Getting started with a developer portal for digital finance APIs

Paystack didn’t start out with all of these assets. What we are seeing on the CGAP Dashboard, where we track the open APIs that DFS providers like Paystack are making available, is that often DFS providers start with a basic landing page for their developer portal (often created as a subdomain in the format developer.companyname.com), API reference documentation and their terms of reference. From there, they might add support via Twitter or Slack, FAQs and so on until they have a full suite of support content. By adding a developer portal feature or two each month, they ensure that they are offering content for the full developer journey.

Open APIs can help DFS providers forge new customer relationships and business partnerships, increase efficiencies and open up new revenue models. And it all starts with the developer portal.