APIs Over IPAs 16: API-First Strategy for Banking Platforms with Dave Biesack, Apiture
In this episode, Derric Gilling sits down with David Biesack, Chief API Officer at Apiture, to discuss building an API-first, customer-centric digital banking platform from the ground up. David shares the origin story of Apiture, a joint venture born from a vision of open banking, and how his team embedded API design and governance into every layer of the product. From establishing API University to codifying internal tooling and style guides, David explains how they’ve scaled API excellence across product and engineering teams.
They explore the critical role of collaboration between product managers, architects, and API designers, emphasizing use-case-driven development, robust internal tooling, and strict security validation. David also talks about empowering partners through a tailored developer portal, balancing compliance with usability, and the cautious optimism around using generative AI in API workflows. Whether you’re managing API platforms or designing developer experiences, this episode offers a wealth of insights into building secure, scalable APIs that actually solve real-world problems.
Listen to the episode on SoundCloud, Apple Podcasts, YouTube Music, or wherever you listen to podcasts. You can also watch the video on our YouTube Channel.
Table of Contents
- Introduction
- Launching the API Program at Apiture
- Customer-Centric API Design
- Measuring API Success
- Regulatory Compliance in API Design
- Building and Enhancing the Developer Portal
- Proactive Security and Partner Guidance
- Handling API Issues and Communication
- Incorporating Generative AI into API Design
- Closing Thoughts and Community Insights
Introduction
Derric: Hi folks, welcome to another episode of Moesif podcast discussing APIs and how to best productize them in the enterprise setting. Joining us today is Dave Biesack, Chief API Officer at Apiture. I’d love to have you here today, David.
David: Thanks, Derric. I’m really happy to be here.
Launching the API Program at Apiture
Derric: Awesome. We’d love to just kick things off and hear about your API journey at Apiture, especially, you know, I know you’ve been discussing being API first and being very customer-centric. How did you get going with launching these APIs?
David: Yeah, well, I mean, I was really fortunate in that I came into an organization that was, as a startup, basically, it was a joint venture between Live Oak Bank and First Data. And the idea was to create an API-based digital banking platform for credit unions and small community banks across the United States. And the name reflects that. Our company name Apiture starts with API. And that’s intentional. It’s kind of a play on words when you think about cameras and Apiture. You know, Apiture is wide open. And that’s what we’re trying to do is create open banking. So, again, I was very fortunate in that I came into an organization that was already thinking API first. They wanted to build an API program. And with my prior experience at SAAS in building an API program there and running the API Center of Excellence for about five years, you know, I had a good background in kind of what’s necessary to put together an API program. What are the key elements that are necessary to keep track of over time? And so, that’s when I started. So, I came in when the company was founded. I was actually the first outside hire to join the company at its founding. Well, one of the very first. And came in really kind of running to say, okay, let’s create an API program. So, I did a lot of things. Primarily, it was kind of educating folks. So, I put together what at the time was called API University. And it was basically just an online peer learning program for people to learn about APIs and what it means to be API first. I wrote one of the first blog entries at Apiture about, you know, what does it mean to be API first? And just kind of going on from there. I created a set of API design principles that kind of guide the way that we design APIs, trying to put the customer and the use case first. And that’s really what I’ve been doing ever since is really trying to focus on collaboration with the other stakeholders at the company. Primarily, the people in our product team who are the ones that envision what we want the product to become. What are the new features we need to add to stay competitive or to meet customer needs and things like that and they come along and say, we need to add this particular product. You know, we want to support credit unions better. So, let’s add the ability to create member-to-member transfers, for example. We identify what the need is. What are the end-user use cases and stories that they need to be able to use with the software. And that drives our API design. And then that comes to my team. We’ve got three API designers on our team. I’m one of them. And that’s primarily the most work that I do is API design. But then we take these requirements from the product team, and then using our style guide and previous experience with our APIs, we design new APIs that satisfy and that fit into the suite of other APIs that we already have. And then we work with people, architects, et cetera, to help with the implementation of that. And we go from there. But a big part of it is maintaining that API-first nature with the rest of the organization. So, people are thinking—and we often do—you know, we need APIs to solve this problem. Or how can we employ APIs to solve this problem? So, it’s been very successful.
Customer-Centric API Design
Derric: I really like that. Not just taking the API-first approach, but being very customer-specific and use-case-specific before even jumping into, you know, implementing some APIs. And otherwise, you know, we’re never going to be solving any actual, you know, business problem. But you’ve been at Apiture since the very beginning. We’d love to hear, you know, how has the different use case expanded? And how do you make sure that you’re still focused on those use cases, even though there’s more and more added? You know, we know, especially in, you know, finance and banking, maybe a lot of different complex use cases and transactions and endpoints. How do you make sure that the APIs stay simple and easy to understand?
David: Right. So, there’s a lot of different answers to that question. The first of which is I have to really give a tip of the hat to our product team, because they’re the ones that handle that first—the answer to your first part of that question. How do you keep track of everything? Okay. So, they’re the ones that know what the features are, what the product does, and where the gaps are, what the customers need, what new features we need to add. And they’re the ones that tell us, you know, we need to add this new feature. So, we have, for example, a couple years ago, we had a pretty major initiative to redefine the way that business banking is done in our platform. So, it was taking our user interface and redoing that to understand what problems customers had, what speed bumps did they have, or what other types of issues do they have that made the current or the older system harder for them to use. So, how do we improve the system to make it easier for them to do things, especially when you get to things like doing wire transfers? Customers are very nervous about wire transfers because once you hit send on a wire transfer, you know, it’s gone. You know, you can’t recall it. You can’t say, oh, wait, I changed my mind. So, we want to make sure the customers are really familiar and comfortable with those types of features so that they’re sure that when they do send a wire, that they’ve got everything right. So, it involves a lot of things like validating the data and things like that. And there are business processes that we support. So, there are approvals within a business context, a business banking context. You may have other people within your business that have to approve a wire before it actually gets sent to the bank. So, it gets staged in an area and people can review those and approve them. So, that’s really what our product team does is they understand the business use cases. And they’re really, really excellent at that. And then our job is to translate those business use cases into technology, into API designs. And then we also have really good architects on the team who understand how the system is built, what capabilities are already there. And as I said, this was a joint venture. So, we inherited a very robust and mature online digital banking platform that we were adding APIs to as we’re evolving. So, we’re adding new features; they have to be implemented within that backend system. So, we rely on the architects to tell us what’s possible, what’s not, what kind of constraints do we have to make the API work within in order to satisfy those needs. So, that’s a hard part, but we also rely very heavily on those architects to tell us how we can do things. And that impacts a lot of—sometimes it impacts the API design—but in a good and reasonable way because it reflects reality.
And then the rest of our job, as I said, is that translation mechanism of taking those requirements and then mapping them. So, we take into account our style guide, and we have some tools to automatically generate APIs. So, we can put down a very high-level abstract description of what an API needs to do and say, for example, we’ve got a new resource. So, say it’s going to be a wire transfer or an ACH batch or something like that, or an ACH template to be able to create future batches from a template. And we determine, you know, what are those resources and what are those operations that need to be captured? And we have some tools that can automatically generate—you know, if we want to follow standard patterns like the simple CRUD type operation—create, read, update, delete, and list. You know, we have stuff that can automatically generate, you know, from a very concise representation of what a resource is, it can generate a bunch of stub OpenAPI boilerplate code. And then we can fill in the blanks to fill in the details of what’s in most schemas and things like that. So, we have a lot of tooling that can accelerate our work. But that tooling kind of is custom-built at Apiture. So, we built it all in-house because it understands our style guide and our idioms and our API design patterns of use and things like that. And so, you know, it understands how to do things like pagination in a consistent way. It understands how to reuse the standard application size problem plus JSON error response or problem response, you know, if there are problems with the request. So, it understands, you know, if there are any kind of syntax errors—you know, you specify, you pass a string where a number is needed or you pass an object where an array is needed. So, you know, we have all kinds of standard practices for handling things like that. And we fully believe, and when I mentioned earlier, you know, we have these API design principles and our first principle is security. We’re doing online banking, digital banking. So, security is of utmost importance. Securing the customer’s data, securing their access to that data, et cetera. So, we always consider API security as one of our very first constraints in our design process. So, validating input is really, really crucial. So, it’s a kind of a zero-trust model. We always validate all input that comes in. We never trust that the data is correct, right? We always validate it against the JSON schema, and we really employ JSON schema as part of OpenAPI very heavily. And that’s a big, important aspect of what we do. So, these tools kind of account for that. And we use spectral linting and use the OWASP API security top 10 rule set as part of spectral to help us ensure that we haven’t forgotten anything by accident.
So, our design process and our tools get us most of the way, but it does take, you know, human intelligence to actually look at something and say, is this right? Does it actually map to the requirements that we have? Does it actually solve the problem at hand? We can’t do that through automated tools and things like that yet. Perhaps AI is going to get there, but I think it needs a little bit more than what we have now with generative AI. I think it’s going to be closer to AGI, you know, general AI. But anyway, that’s in the future. So, right now we sort of rely on human intelligence to do that verification—is this design really going to work? And then we iterate too. It’s an agile process. So, we can give the API design and then the developers will start implementing it. And if they run into problems—oh, there’s an inconsistency here, or this particular piece doesn’t really work—you know, we will tweak the API design early in the process to account for that. But everybody is kind of on board with this supporting, you know, getting the APIs as a foundational piece of what we do and building from there. It’s pretty fun.
Measuring API Success
Derric: I like that—taking this API standards approach, making sure that pagination is done, you know, the same way across the entire platform, not just for, you know, internal use and for usability, but that’s also a trust and security thing as well, right? Making sure that you are conforming to certain standards and, you know, thinking about things like API governance. I’m curious, you know, as you’re thinking about launching new APIs, how do you measure success, right? You know, if you want to drive API excellence at Apiture and baking security and governance into that process, what does that look like when you’re shipping a new API, and is there some type of checklist that you walk through?
David: Most of it is driven by, you know, can the front-end team build the application that they want, and how difficult is that, or how easy is it for it? And does it cover all the use cases? So again, you know, we’re building on knowledge of what we’ve done in the past. So we have these kinds of patterns that we can reuse and call upon when we do this type of work. So the measure of success there is most of the APIs that we have are really kind of internal APIs. We have our own proprietary—it’s kind of our own white-label web application, and we also have a generic mobile application that we then customize for each individual financial institution customer or client of ours. So each bank gets their own app that goes into the app stores for their banking customers to download when they want to use online banking with their mobile devices and stuff. So we build all that. So the primary use case for most of our APIs is our own internal systems. We do have these public APIs. We document them on our developer portal. So, and then we just look for feedback from those customers who are using those APIs. Can they solve the business problems that they’re really interested in? And we’ve had good success with that.
Derric: Definitely going back to what is the original problem they’re trying to solve. At the end of the day, this is what we’re all trying to use APIs for, right?
David: Right, right. Yeah. So we start with, you know, what are you trying to do? You know, what problem are you trying to solve? And then ultimately, does the API let you solve that particular problem? And that’s the feedback that we’re most interested in.
Regulatory Compliance in API Design
Derric: Makes sense. And, you know, when we talk about things like open banking and, you know, access to customer data, how do you incorporate that into the API design process, ensuring that new regulation and compliance is actually met as well, and then balancing those customer needs between enabling these new use cases while at the same time helping customers stay compliant with the new regulation coming out?
David: Right, right. So again, I’m not a banking expert. I’m not a regulation expert, but I do rely on our product team to be the domain experts in that realm. So they tell us what has to be done and what’s necessary. So, you know, when you get into banking, critical things are okay—you have to have the right disclosures so that when a new customer comes on board there, they can see those disclosures and we can capture their acceptance of those disclosures. So those parts of the compliance aspect or the regulatory aspect of online banking, open banking, really come in as product features as to what has to be done. And we codify those in API designs. So we have like a disclosures API that can list the disclosures related to a specific banking account product. So if you’re going to open up a new checking account, right, here are the disclosures that we expect you to view and accept. And then we capture that information as part of our digital account opening solution in order to comply with those types of regulatory compliance things.
Building and Enhancing the Developer Portal
Derric: Makes sense. And you mentioned, you know, building out a developer portal—how do you help empower your partners to make sure they’re able to find the right APIs that they’re looking for, for these new use cases? Especially, you know, there could be a lot of different ones, right? A large bank versus a smaller credit union—I’m sure they have very different needs. And how do you, you know, balance both needs at the same time?
David: Yeah, right. So we have a two-pronged approach for our developer portal. Part of our developer portal is generated from source. So we have a source project in a Git repository that captures the developer portal. And when we have a new API, we just add—we have a JSON file that lists all the APIs that are published on our developer portal. So we just add a new API to that JSON list, regenerate the portal, and publish that out. And so that is fairly automated in that regard. Not fully automated because you have to go in there and manually add it to a list, but that’s a decision that you have to do. Someone has to make a decision that, okay, this API is done, this API is in production, now we’re going to document it on the developer portal and make it available. So that’s okay—it’s done that way.
We have another part of our developer portal, which is really kind of managed sort of as a WordPress site. So, you know, our technical writers can go in there and add documentation that explains how to use certain APIs or certain scenarios and things like that. So we have, for example, one of our APIs, which is kind of critical for fraud detection and fraud prevention, is an audit or banking events API. So as things occur within the digital banking system—as a customer schedules a new transfer, or as a customer tries to even log in and fails a login attempt—we generate events to capture all this information, and it goes into this event history API.
And so our partners can then—once we provision their access to that particular API, if it’s a secure client that we trust—they can look at all these banking events, all this banking data, in order to do fraud detection, for example. And so we have a partner, DefenseStorm, that we partner with very closely. And so when we have an FI client, a financial institution client working with us, they can basically license access to the DefenseStorm product. And then that integration is very tight with us. So they can look at this data and use our APIs to get information.
So that’s kind of how we try to view this, is we make those APIs available through the developer portal. Partners can come in and register, and they get access to—they can register a client application and then get credentials to authenticate against our APIs and things like that. So all that works really, really nicely and is pretty good and mature enough. What we’re going to do next is integrate things like Moesif into that developer portal so that, you know, if I’ve registered my client, I should be able to come back in and just see, well, show me what my API traffic is looking like for my client. We don’t have that yet, but that’s on our roadmap for 2025—to have that type of integration. So they can get the Moesif data and get some analysis of, you know—oh, you know, my client is misbehaving. I’m seeing a lot of 400 errors on this particular API call. Maybe I’ve got a defect in my client, you know. And we have a sandbox area where they can develop their client application against a kind of a sample or test financial institution and build and test their applications prior to them going production.
We segregate API access between dev and test and QA and prod. So you can’t use credentials for your test application in production, and that’s all managed through our developer portal. We kind of keep those things separate, so you can’t just start developing something and then use it for a production instance. And we encourage people to maintain their credentials securely and things like that.
So that’s our primary kind of success metric—is how many people are using the developer portal, how many applications are being registered, and then eventually using Moesif to look at what their API traffic is, and seeing that they’re building it and they’re being successful with that.
Proactive Security and Partner Guidance
Derric: Glad to hear, and super excited to see that launched later this year. You know, speaking more around API excellence and these different very specific use cases that can be quite critical to make sure you get it right—you know, you talk about using the right credentials in a production setting versus a sandbox environment, and what goes into setting that environment up to be secure and follow the right best practices. But as a follow-up to that, how do you best support your partners to make sure they are following these best practices, things that may not even be inside your control, right? Is there any type of influence that you do there, or is this something that’s baked into the API design itself?
David: So, we try to engender these partnerships as much as we can. So we work with partners and communicate. Like, even this week, we have one partner who came in and requested a client application, and they specified, okay, here’s the description of what the application wants to do. And it was basically going to be similar to what I mentioned earlier about kind of pulling the events within the banking system in order to do fraud detection and then feed it into a third-party fraud detection system. And they requested a client application and credentials, and when they do that, they list which APIs are you going to be hitting, and which environment are you going to be talking to—which financial institution—and is this going to be for a QA environment, or is it going to be a production environment, et cetera.
And they listed what they needed, but that they included—and when you do this, you select the APIs that you want to use. And then from those APIs, we extract out all the OAuth scopes for all the operations within those APIs and give them a list and say, “Which scopes is your client going to use?” And they had just checked all the scopes that were available, unfortunately, right? So it included read scopes, but also included write scopes, you know?
So we see that when it comes in at the request. And even before we go any further with that, you know, then we go back to the customer and say, “Okay, did you really intend to do this? The description of your client looks like you’re trying to read data, but you’re asking for write scopes. But I don’t think you really intended that.” And it’s, “Oh yeah, you’re right.” And so they go back in, and our developer portal—we have a very easy checkbox—you go in and you select all these APIs, and you can have one checkbox that says “Exclude write scopes,” which basically means you’re a read-only application, right? And so it’s very easy for them to fix that. And so they do that.
So we catch those types of things again with manual inspection before we go any further with a request. Once everything looks good, then we go back to the financial institution and ask—we have a list of approved authorities at each institution—to say, “Here’s a client that is trying to build an application, and they want to be able to access data on your financial institution.” And oftentimes, it’s a partner of that financial institution or someone in their IT shop, you know? So it’s pretty obvious they’re developing something internal in-house.
But anyway, we do that check anyway. We always ask them, “Do you want to grant them access to this?” And when they do, then we come back and we provision that access through our developer portal. And then they get notifications to say, “Okay, your access is granted, and you go over here to get your credentials and stuff.” So that’s a very robust process.
I created our first dev portal, I think it was 2019, and we’ve been evolving it ever since. And we have lots of different types of API access or access to our platform. So the majority of it is API access—you’re just going to use our APIs—but we also have a feature called embedded banking, which lets you build your own custom application for your customers in whatever domain or market that they’re running in. So it might be a vet clinic or something like that. But they want to embed banking components inside their application to view your account and see, you know, “Do you have enough funds in there for your capital campaign you’re just about to start?” et cetera. And so they can embed these digital banking components inside of their applications. That’s an embedded banking solution.
So we have a way to register for that in our dev portal. And as I mentioned before, with these banking events, we also have a webhook facility so that you can register. And then when these events occur, you can listen and subscribe to getting certain events of different event categories. So they come directly to you through a webhook that you register with us. So we have all these different types of things that we register in our dev portal.
And that’s what’s nice about kind of building it ourselves—is we have all these different needs because of what we do that you can’t get from an off-the-shelf developer portal that just says, “Okay, well, here’s your API doc. Go in here and get an API key,” or something like that. So it’s more sophisticated than that. But it all hinges on understanding the use cases and what our product provides and what our customers want to be able to do, what problems they’re trying to solve. And then we kind of marry the two.
And then we have a great support team here as well. Actually, they’re kind of an award-winning support team, which is really kind of exciting. And so we’re kind of growing them into this right now. They typically support kind of the end customers and then our clients who are running their own bank—they’re running our software to manage their bank. And so we have an admin platform for the bank and things like that. And so, you know, most of the support is focused around that and then training for how to do that, how to use the product, et cetera. But we’re getting into more and more support for these third-party applications coming in and connecting to our platform.
Handling API Issues and Communication
Derric: It definitely sounds like having a very tailored onboarding process and taking that proactive approach to security—that’s really how you help enable your customers and partners to be successful, much more than just let them deal with it and see what happens, right? And that’s, you know, taking that very customer-centric thinking approach. When things do go wrong, you know, how do you help your customers? You know, they had a risk or they messed up somewhere, and it could be a security risk. What are some best practices that you’ve seen in terms of keeping folks informed and trying to make sure they’re on their path to succeed with the platform?
David: Yeah. So, we haven’t had too many of those types of issues around the API-focused areas. So most of those types of things—really any type of those problems—go directly to our customer support team. And they’re the ones that manage that, and they perform—they do the communications. So we have customer success managers with each of our clients and things, so they’re the ones that do that communication to get things cleared up. We’ve been fortunate. We haven’t had any kind of major issues with APIs and things like that.
With API evolution, we’ve had a couple of cases where, due to things like security or changing, evolving practices and things like that, we’ve had to make a couple of API changes that would affect customers—sort of like breaking changes, you know. They do need to update their system to account for this. But they weren’t really breaking changes, but we were just changing and say, “Okay, the implementation is changing a little bit. So we used to give you this information, but now that value is no longer there; this is replaced with this other value.” So we always try to communicate as much as we can for things like that, to share what’s happening and then have release cycles planned ahead, so we can communicate release notes, you know, what’s changing in the system, to give everybody a sufficient heads-up so they can plan accordingly.
Derric: Definitely over-communicate versus under-communicate. No one wants to wake up to a four-in-the-morning PagerDuty alert, right?
David: No, of course not.
Incorporating Generative AI into API Design
Derric: Well, my last question was just around how Gen AI is impacting your API design, API-first process. We keep hearing quite a bit about it. But how do you think about, you know, Gen AI tooling and, you know, incorporating different Gen AI tools into your API process?
David: Yeah, we’re still kind of nascent in that space yet. What I’m hoping is that—we’re looking at various options there—I want to be able to get to the point where I can feed a generative AI system our existing API designs and our style guide and our spectral rulesets and things like that, such that then we can say, “Okay,” and maybe some of the other stuff like our tools that generate APIs from these concise descriptions and stuff. I think there’s a lot of potential there. We haven’t incorporated it yet—we’re still kind of looking at where that’s going to go. But definitely, you know, the company overall is very interested in seeing how AI can help the people who are on staff be more productive and get more done and do so with assurance.
So I think the important part there is to treat an AI entity as a junior programmer for a while, at least until they can prove themselves, but employ the rest of your best development practices to that work. So, you know, if there’s any kind of code that you’re getting from an AI—from a generative AI type system—make sure it’s going through all of your regular code audit processes. You know, it’s going to be writing code, it goes through a peer review through pull requests and things like that through your Git repo, et cetera. But treat it—don’t treat it as trusted until you’re really proving that it’s doing what it’s supposed to do. But do code reviews on that code and things like that, and make sure you have good regression tests. And in our case, you know, we want to have good security tests. And that’s where I mentioned things like the spectral OWASP top 10. So that would be one of the things you’d want to feed in as your prompts—to follow this set of rules.
And I don’t know yet how you create correct prompts to say, you know, make sure that when you define an API, all of your requests have a security requirement on them, right? We have no unauthenticated APIs. Every API has to be secured. But in our case, you know, we’ve got lots of different types of APIs and lots of different types of API consumers. There are APIs that are meant for a front-end banking customer, right? I want to list my accounts—so that requires one type of authentication, an end-user authentication. But then we have systems that talk to each other, so we use client credentials. All of our APIs—we want to have OAuth authentication on them, OpenID Connect, and things like that.
So we have to be able to have enough information to guide an AI to say, “Okay, this particular API is targeting a secure back-office application as the client, so its authentication model is going to be different than an API that’s being used by the end customer, which is using authorization code grant flow.” So, you know, we have to have that kind of thing built into our system before we can effectively use it. And the same is going to happen with generating your schemas for your API, for your request and response bodies. You know, we have a lot of patterns that we use. And I’ve documented a lot of these. I’ve got a Substack called “API Design Matters,” and I’ve kind of talked quite a bit about common API design patterns and strategies and quite a bit of stuff on using JSON schemas and stuff. So we kind of want an AI that can understand how we compose schemas to have maximum reuse, so we don’t have a lot of copy and paste.
And we’re seeing right now—there’s kind of a lot of analysis when people look at what’s happening more recently, now that these AI systems are out there, whether it’s with Visual Studio Code and things like GitHub Copilot, et cetera—people are starting to see a lot more copy-and-paste-type stuff in these Git repos. And that’s just in the open-source stuff that they can do analysis on. And that’s what happens when you have these AI systems. It tends to be kind of copy-and-paste-type stuff. And, you know, so I’m still a little bit hesitant about how well they’re going to work. But I think by integrating them in but still having oversight over what they’re generating to make sure that it’s still secure and it solves the right business problem and it fits the style guide and things like that.
Because really, APIs—there’s a lot of metrics for how an API is considered good, right? The first of which is: Does it meet the business needs? Does it solve the right problem? Right? And you can use the API to actually get what you want out of it and solve a problem. That’s the first thing. But then there’s a lot of heuristic-type things, right? How easy is it to use? How well is it documented? How complete is that documentation? And we found, with kind of case studies—I’m a really huge advocate of having good documentation. I don’t want rote documentation that, okay, well, property X means this is the X value for this object—it doesn’t tell me anything, right? You have to tell me what it actually means. So I’m really kind of adamant about having good documentation that explains what the API is, how it’s used, so it’s very complete.
And that really helps with AI—if you have something that’s doing code generation against the API. And we’ve had quite a bit of success with that in the research efforts that we’ve done, where we feed our API definitions to the AI, and then they can generate code to use that API. And it’s actually pretty good because we’ve got good documentation that captures that. So I’m really interested to see what we can do to add semantics to the API so that they understand really what it means.
So some of that is kind of , but I’d like to be a little bit more explicit, because I want to have that information there. It’s pretty easy to know—you’ve got a POST operation that creates a resource. And then there’s a GET operation that kind of returns that same resource. And then there’s a DELETE operation to delete it, and there might be a PUT or a PATCH to update it or edit it. And that’s kind of well-understood. But then there’s a lot of other things on the edge. So there may be other operations that do actions on behalf of you. So there may be—like with a debit card or credit card resource—you know, you can certainly see here’s a GET to get that particular resource. But then there’s another POST operation that’s kind of adjacent to it that says, “Okay, I want to lock that card because I’ve misplaced it. I don’t want someone using it accidentally. So I’m going to lock it so that no one can use it until I come back in, and I’ve found it, and I can unlock it.” So that’s kind of an adjacent thing. That’s a POST, and it’s not very clear from the standard patterns—like a CRUD pattern—how that fits in. So, you know, you have to make sure that an AI can kind of understand that.
So, if you can identify the semantics—and some of that is in the description of what the operation does, right? Because the operation name is “lock debit card.” So, it’s kind of obvious, but the description says, “This locks the debit card so that someone can’t use it until it becomes unlocked,” you know? And so that helps someone who then wants to be able to employ an agent to say, “Hey, give me a list of my credit cards.” You say, “Oh, you’ve got two credit cards with this bank,” and say, “Okay, I want to lock the first one,” right?
So, AI should be able to figure out, well, that’s going to map to this “lock debit card” or “lock credit card” operation. And if then it says, “Okay, well, I’m going to try to lock this. Is that what you want to do? Please confirm.” You say, “Yes,” and the agent goes off and does that. So that’s kind of where I think things are going to evolve in the near term, is to allow these agents to be able to use APIs.
But I think what we need is something akin to a robots.txt file that tells a web robot—a bot that’s out there—can you navigate this site? Can you spider it and find out all the resources on this particular website? And you have to look at the robots.txt file. And so Google can’t index it, for example, or Google can. And the same thing—I think we need the same type of thing for APIs. We may have some APIs that are low-risk and say, “Okay, it’s okay to allow an agent to be able to invoke or use this API on behalf of a customer.” But this API is really sensitive, or risky, or potentially dangerous, and we say, “Well, we’re not going to allow an agent to access that.”
So I think that’s kind of the next phase that we need to look at with talking about agents and AI and APIs.
Derric: I like that—treating AI as a junior developer, making sure it’s embedded in your change management process. But on top of that, some of these APIs can be really risky. That wire transfer thing that you mentioned—what if someone didn’t even realize, you know, it was copy-pasted into some generated code, and suddenly it was supposed to read the wire transfer, but it actually sent it, right? Like, there’s a lot of risk when we start thinking about these types of banking platforms.
David: Yeah, we definitely need feedback loops and things like that to ensure that the AI is doing what you expect it to do. And people have to be careful. You can’t be complacent and just say, “Oh, that looks good. The code compiles—push it.” That’s not sufficient. So we have to be very careful.
Closing Thoughts and Community Insights
Derric: Definitely. And having this API governance and having the right process there, regression testing—hopefully, it catches these things. But it’s really around the process of how do we ship APIs to meet the requirements but at the same time fitting all the security rules and everything else that you have. But really appreciate having you here, David—talking about APIs, having an API-first mindset, especially in the finance and open banking and banking space. Any parting thoughts that you want to share before we end the podcast?
David: So, anytime I talk to someone about APIs and kind of the API space, I always want to reiterate how grateful I am for the community that’s around us. So these are the people that you meet when you go to conferences or you go online—whether it’s just LinkedIn or some other place—or you’re looking at Moesif. The community here—and we’re all very, very supportive. So if anybody’s getting into this space, reach out. People are so willing to help because everybody’s very passionate about APIs. And they know that they’re critical for business success. And they know that it’s critical for people to build these API skills. And so everybody is very willing to help everybody else grow.
So I’m very appreciative of all the people who have helped me over the many years that I’ve been in this space and have been very welcoming in letting me come to conferences and talk or come on podcasts and things like that. So just kind of turn that around. So don’t be afraid to reach out. And then when you learn something, share it, you know—share it back. So I just want to make sure that I get that out there.
Derric: Yeah, that’s fine. I mean, the API community—it’s a small, close-knit community. But we’re all very passionate about APIs, and it’s growing. More and more companies are thinking about treating APIs as products, and more folks are branching into API product management. And these newer types of roles are being created. But at the same time, it is a small community, and I’m thankful as well to learn about APIs and branch into this space as well.
Well, thank you very much, David. And have a good rest of the week.
David: All right. Well, thanks, Derric. It’s been fun.
Related Articles
API Development
AI Application with Vercel and NextJs with Moesif for Analytics
Building AI Application with Next.js with Moesif for Analytics and monetization.
API Development
WSO2 APK + Moesif API Analytics: Drive API Performance and Adoption
Learn how you can drive API performance and adoption in WSO2 APK with Moesif API analytics plugin.
API Development
WSO2 Choreo + Moesif API Analytics: Optimize API Performance And Drive Adoption
Learn how you can optimize API performance and drive adoption in WSO2 Choreo with Moesif API analytics plugin.
Podcasts
APIs Over IPAs 15: Customer Observability with Mike Amundsen, Amundsen.com
Derric Gilling sits down with Mike Amundsen, a leader in the API ecosystem, to explore the role of observability in API design and customer experience.