A Tale of 3 Challenges: Integrating and Standardizing APIs

Jason Harmon CTO
by Jason Harmon CTO on June 15, 2023 5 min read

This week on the API Intersection podcast, we interviewed Chris Turner, Senior Software Engineer and Agile Practitioner at Segovia Technology, a Crown Agents Bank. Crown Agents Bank uses computer systems and APIs to move money between countries, particularly in Africa.

With his current role, Chris emphasizes that he could very well be working with one organization or agency with a modernized, high-technology stack that needs to integrate with an organization whose main form of technology is an array of spreadsheets.

There is a level of complexity and nuances involved in working with APIs across different domains and industries, particularly in the context of Crown Agents Bank’s mission to facilitate cross-border money transfers. With such a stark variety of diverse integration partners and the complexity of their APIs, building a standardized API program is all the more critical.

We dove into the challenges of integrating with legacy systems, integrating a variety of third-party systems, building diverse APIs, and how to manage different levels of sophistication between African banks and mobile network providers.

The Challenge: Limitations of Generic APIs and Sporadic Connection

There are limitations of generic APIs and the difficulties they can present regarding understandability, implementation, and testing. Instead, Chris suggests focusing on domain-specific APIs and applying specific software engineering techniques to build robust and manageable systems.

One of those techniques involves a concept called Command Query Responsibility Segregation (CQRS) and its relevance to their work. His team will utilize standard modeling practices and the Axon Framework, which implements CQRS, to handle event sourcing, asynchronous messaging, retry events, and resource management.

“There’s a ton of resilience and reliability aspects of connecting with multiple providers, especially in developing markets like Africa,” shares Chris. “We also use strategies such as retry, backoff, and queuing mechanisms to handle intermittent connectivity and ensure sequential processing of payments.”

The Challenge: Difficulty Aggregating and Standardizing

With so many APIs in so many varying levels of complexity, it can also make the aggregation of APIs difficult and creates a standardization challenge. Add legacy systems on top of that, and consistency becomes even more challenging.

“It’s important to create a common view of APIs without attempting to aggregate them all into a single solution,” shares Chris.

To combat this, putting a solid governance program in place will help to promote and enforce standardization. Tools like style guidelines can give specifics about functions, classes, return types, errors, arguments, etc., and can be used to enforce standardization across an API program.

However, a governance program includes more than just a few style guides, so check out this blog to learn more about crafting a strong governance program. The major activities that API governance includes are descriptions, contracts, designs, protocols, and quality Reviews.

Focusing on standardization helps ensure that all your APIs remain consistent even when different developers design and build them. An effective API governance program helps organizations ensure that ‘every API is high-quality and discoverable—whether they create a few APIs or a few thousand.’

The Challenge: Diversity and Complexity of APIs

“Every new provider comes in and adds a bit to it, and you end up with a core with all these little extensions that go off of it. It actually becomes such a big blob of stuff to try and get your head around and implement. It would have been so much easier just to have half a dozen very simple APIs,” shares Chris.

With a variety of international organizations scaling from small local startups to global nonprofits, the amount of diversity and complexity of APIs that Chris’s team deals with on a daily basis is quite high. One solution for folks in a similar situation is to look at cataloging your APIs to ensure there’s a strong understanding of what you offer and where they stand. Enhancing visibility and discoverability across your API program will help to break down the variety of APIs offered and increase understanding.

“With such diversity in APIs, there is a huge need for specific implementations for each provider we connect with. For example, with the unique payment methods prevalent in Africa, such as mobile phone-based payments, and the varying levels of API integration and reliability in the region, it can be a challenging development problem,” shares Chris.

Cutting through the thicket of information sometimes requires a tool that helps you impose order. An API catalog can give you and your users a better view of the whole garden of tools you’ve got growing so that you can prune away the excess and find the ones that will serve you best.

Another one of those strategies to combat a diverse ecosystem of APIs is constantly testing and retesting your APIs. Chris’s team will often experience challenges of replaying events in testing with the goal of creating a simulation of unreliable services for testing purposes so that they know how their APIs will act in those situations when they happen. By constantly testing, they can ensure that things will operate as they should, even in the harshest environments or the most diverse APIs.

Overall, I always enjoy diving deep into someone’s API program and unique challenges, both of which Chris has one of the most unique ones I’ve seen! But his challenges are issues that we all face when building out our own API program, so they’re worth learning from. For more advice from industry leaders, check out the API Intersection podcast.

Share this post

Stoplight to Join SmartBear!

As a part of SmartBear, we are excited to offer a world-class API solution for all developers' needs.

Learn More
The blog CTA goes here! If you don't need a CTA, make sure you turn the "Show CTA Module" option off.