When we begin conversations with clients, we often get faced with: Are we an API or SDK? The just of this, for those who don’t know what the acronyms mean just yet, is whether we are giving developers the rules of engagement, a way to connect into our system, or are we providing the entire toolbox for building?
This distinction is an important one for our clients (and for anyone trying to get a lay of the land in this ecosystem). Gathr is an API marketplace, which means we provide the connective tissue of the digital economy. APIs give businesses the flexibility to choose and scale the solutions they need. We offer an open environment where clients can build on their own terms – integrating with us to unlock new ways to collect data and generate value. While we’re not an SDK yet, it’s something we’re looking to explore further down the line.
Let’s get down to the nitty-gritty first: not just understanding what these acronyms stand for, but how they actually work, how they differ, and how they show up in real-world examples here in South Africa.
Here’s a clear and practical rundown (complete with a creative metaphor) on the differences between these software ecosystems, courtesy of our Junior Software Engineer, Ryan Lake. Ryan decided to make things a bit more fun and memorable by comparing them to a restaurant experience:
- API is the menu and the waiter: you order a dish (functionality) without needing to know how it’s prepared.
- SDK is the entire kitchen: complete with ingredients, recipes, cookware, and staff needed to create the dish.
- APK is the final plated meal: ready to be served to the customer.
- ADK is a robotic sous-chef: equipped with the tools to observe and act independently in the kitchen.
API: The Rules for Engagement
We’ll start with the one we know best – An API (Application Programming Interface) is like a set of ground rules. APIs are like waiters at a restaurant. You don’t go into the kitchen to cook your own food, instead, you tell the waiter (the API) what you want. Behind the scenes, the kitchen (the system or server) processes your request and delivers your meal (the response).
“At its core, an API defines how two systems talk to each other, what questions one can ask, what format the answers come back in, and what actions are possible.” Ryan Lake, Junior Software Engineer.
For developers, an API is incredibly flexible. They don’t need to know how the system is built internally; they just send a request and get a response. For businesses, APIs mean modular, scalable integration, plugging in only the parts they need, whether for payments, logistics, or customer data.
Let’s give you a practical example: Our Affordability API
A financial services provider can quickly assess a customer’s affordability using Gathr’s Affordability API – no need to build a system from scratch. The provider’s system simply sends an API request to Gathr with a customer’s bank statements. Behind the scenes, Gathr normalises and categorises the data before returning a clean, structured JSON response containing the processed data and affordability insights. The client then applies their own affordability logic. The provider doesn’t need to understand how Gathr ingests statements or maps categories – they just send the right request and trust the accurate response.
Pros & cons of using an API:
Pros:
- Easy access to services like payments, maps, or data.
- Work with any programming language or platform.
- Scalable and modular for flexible integrations.
Cons:
- You can only do what the API allows.
- If an API fails, your system needs to handle it.
- If the provider changes or goes down, your app may break.
SDK: The Full Development Kitchen
An SDK (Software Development Kit) is like receiving an entire kitchen in a box. It comes with all the utensils, ingredients, and recipes you need to prepare a specific type of meal.
Think of it as more than just a set of rules, it’s a complete workspace for developers. Alongside APIs, an SDK typically includes libraries, testing tools, and documentation, all tailored for a specific platform. With it, developers aren’t just given the “rules of the game,” but also the tools and step-by-step guides to start cooking right away.
Let’s give you a practical example:
Gathr leverages a library called poppler used for PDF processing. Poppler comes in two forms, a standalone library and an SDK. The SDK packages the functionality of the poppler library with an API allowing development over multiple platforms and languages.
While we don’t offer SDKs just yet at Gathr, they’re very much on the horizon. As part of our upcoming rollout, we’re exploring ways to introduce SDKs that will make integrations faster and smoother. Exciting things are on the way – so keep an eye out.
Pros & cons of using an SDK:
Pros:
- Speeds up development and integration with pre-built tools.
- Optimised for the platform they’re built for.
- Includes testing tools, emulators, and debuggers.
Cons:
- Can be large and complex, with a steep learning curve.
- Usually tied to a specific platform.
- Need regular updates as platforms evolve
APK: Plated Dish
An APK (Android Package) is the end product, an app you can install on your phone. It’s the plated dish served to the customer, containing all the compiled code, assets, and configurations needed to run.
What’s a South African example of an APK:
Well, this is pretty much any Andriod app, a well-known example of an APK is EskomSePush. This app was packaged as an APK and made available on the Play Store, allowing everyday South Africans to easily monitor loadshedding schedules.
These are ready-to-use experiences, but they illustrate why Gathr isn’t an APK. We don’t deliver the final, installable product; we deliver the building blocks others use to make those products or use inside of those products.
Pros & Cons of using APKs
Pros:
- Easy to share and install on Android devices.
- Precompiled and optimised for performance.
- Can work offline once installed.
Cons:
- Only works on Android
- Security risks if downloaded outside app stores.
- Hard to debug or change once compiled
ADK: The Robotic Sous-Chef
An ADK (Agent Development Kit) is a modern toolkit for creating intelligent software that can make decisions and act independently.
Let’s give you a practical example of an ADK:
A common example of an ADK is something that many people have probably run into without realising. Chatbots on websites and apps. These were most likely put together with an ADK like Google’s and trained on the context of the website or app. This gives the bot the full scope of what it is allowed to see and prompts users accordingly.
Pros & Cons of using an ADK
Pros:
- Simplifies Agent creation
- Integrates well with ML/AI components
- Extremely versatile (can be trained for many different purposes)
Cons:
- Steep learning curve
- Can have a high-performance overhead
- Difficult to troubleshoot issues due to Blackbox structure
A Quick Summary
Why did we choose the API marketplace route?
For Gathr, we are an API marketplace (meaning a company can easily find and use different APIs). So, our value lies in:
- Enabling modularity (basically you can pick and choose the APIs you need).
- Supporting scalability (integrate new APIs as your business grows).
- Encouraging the mixing and matching of APIs(combine APIs across industries in new, innovative ways).
APIs are the heart of our offering. Whether our clients are building a lending app, a credit risk engine, or a customer onboarding flow, APIs make it easy to embed Gathr’s intelligence into their own systems.
ADKs point to a future where autonomous systems consume APIs without human developers in the loop. But APIs are where the ecosystem begins, and they are exactly what Gathr makes accessible and valuable.
When we’re asked by clients what approach we’re giving them, we provide the rules that open up ecosystems, rules that connect businesses, rules that allow innovation to thrive.
Understanding APIs, SDKs, and APKs isn’t just semantics – it’s about choosing what best fits your business and engineering goals. For us, APIs drive growth by enabling seamless integration, scale, and collaboration. But who knows what the future holds for our engineering team.