Weekly API Evangelist Governance (Guidance)
As I prepare the go to market strategy for our new startup Naftiko I am hyper aware of the state of the market after conducting research on the space for the last two months. I am determined to come out of the gate with a narrative that acknowledges the current grip that artificial intelligence has on the market, while focusing on delivering real world solutions that companies, organizations, institutions, and government agencies need across their operations. As part of this work there are several ways I am grounding our storytelling around what we are building at Naftiko.
API Integrations
Nothing has changed in this moment regarding how we integrate with APIs—despite the popular AI narrative going around. API integrations are always human-centered, led by human developers, providing automated as well as manual ways for end-users to get at the digital resources APIs make available. What is evolving is that we are doing this across more and more APIs and applications, increasing the value and importance of API integrations, but also the standardization and governance of the API integrations that power our operations.
API Authentication
Knowing who is using our APIs, and ensuring those who do have access are able to securely make API requests has been a top priority since this API circus emerged early on this century. We have API keys, OAuth, and JWT to standardize this layer. Developers will always need help onboarding, whether they are human or robots. Authentication will always needing observability and auditing as part of regular operations, ensuring that access to the APIs we depend upon is always as secure as it possibly can be.
API Authorization
Right after a human or robot is authenticated, it has become increasingly critical to have a strong grasp of what they are authorized to access. Security isn’t just about keeping bad actors out, it is also about limiting what they have access to when they do get access. OAuth scopes and other mechanisms have long been in place to help get fine grained about what is accessible by any 1st or 3rd-party developer, providing ways for platforms to consistently manage API authorization, and end-users properly delegate who has access to what.
API Consumption
Understanding API consumption by developers, but also the end-users (human or robot) of the applications they power has been a key tenet of API management since early on this century. Reporting this usage to 3rd-party developers as well as end-users in a real-time or via recurring reports is common practice. All API producers should be understanding how their users consume APIs, but API consumers, both technical and non-technical should have an awareness of their API consumption which encompasses all the data they produce and consume on daily basis.
API Workflows
The order in which APIs are called, which is often dictated by a mix of desktop, web, mobile, device, network, and AI applications, while also often being directed by human users of these applications has been evolving throughout this century. There are machine-readable standards such as OpenAPI and Arazzo to help define what API requests can be made, what responses will look like, and how you can daisy chain together these API requests and responses into workflows that will matter to business operations, but also to the customers buying their products and services.
API Automation
The automation of everything we are talking about today has also been evolving throughout this century, with many proven deterministic approaches to scheduling, responding to events, and automating different aspects of our business operations and personal lives. AI Agents are leveraging all of the same mechanisms our SDKs, clients, explorers, and applications have been using for decades, they are just doing it with more compute and less appreciation for the interface, looking for any way it can get access to digital resources, and leaving the rest to the LLM behind.
Business Alignment
The foundation of API integration, authentication, authorization, consumption, workflows, and automation is being laid with or without AI agents. What is missing with traditional API automation as well as agent driven API automation is the business alignment. This lack of business alignment is why MCP didn’t have adequate levels of authentication and authorization out of the gate. This lack of business alignment is why very few are talking about API consumption, adopting existing workflow standards, and employing existing approaches to API automation.
Business Domains
Business alignment begins at the domain level. What part of the business are these integrations happening? Who is using these integrations? What are they doing with them? And why are they wanting to use them. The business domain should provide much of the context needed for automation, whether it is AI agents or some “old school” proven approach. The metadata needed to articulate the business imperative for why a series of API integrations exist should be available at runtime and review, audit, and evolve time for any integration.
API Plans
The pricing, plans, features, add-on, support, and other elements of our business relationships with SaaS providers must also be baked into ay API integration, ensuring that we fully understand the full cost associated with using any single services, at the application or API level. We should be able to confidently articulate the pricing, plans, features, add-on, support, and other elements across multiple APIs, and be able to conduct a “diff” between any of the services, as well as consider as a whole package when producing new integrations or evaluating existing integrations already in production.
API Rate Limits
Once we understand the plans across the APIs we depend on to power any part of our operations, we need to reconcile the math regarding what we are using across APIs with the rate limits imposed for each individual API resources in use across potentially many different SaaS providers. We should have an understanding of our general daily, weekly, and monthly usage, and have the accounting of where we stand within the SaaS and API plans in which we operate, ensuring we are maximizing every digital resource being purchased and used (or not) across each domain.
API Security
When it comes to topic of API security, we all need a lot of help. OAuth can be complex and complicated. Encryption takes communication and maintenance. Validation helps keep bad actors, and garbage out. Security isn’t a problem that AI is going to magically go away. It is making things harder. We have done a lot of hard work on the security of our digital resources over this decade, and building upon existing API authentication and authentication practices, as well properly defining our API using common artifacts like OpenAPI help secure the surface area of the APIs we consume.
API Compliance
Our API integration, consumption, and automation must be compliant. Compliance spans API plans, rate limits, and security. API compliance centers on how we standardize our consumption across many different APIs, and relies upon the governance of integrations to ensure we are approaching encryption, PII, licensing, industry standards, and follow other municipal, state, federal, and internal regulations. API compliance ensures there is a centralized set of policies that shape how API integrations occur, providing distributed agency across teams, coupled with the proper centralized control needed for business alignment.
Business Capabilities
Naftiko is approaching API integrations, consumption, and automation as capabilities. These capabilities are grounded within business domains, with a firm understanding of the plans, rate limits, and security that are applied (or not) across integrations and workflows. I think there has been proper critique of the lack of security when it comes to agentic workflows, but we don’t feel like there is adequate discussions at the domains, plans, usage, and compliance levels. We are confident that Naftiko can help ground the conversation when it comes to workflow automation.
Business alignment is where the grounding needs to occur in the business workflow automation discussion. This discussion has multiple layers, but it begins with obtaining the proper business context by defining the business domain in which any automated workflow is being executed. From there you must have a handle on the plans and limits of the API resources you are consuming, as well as the total cost of ownership of the automation pipeline—ensuring that your business capabilities are always aligned with the wider goals of your business operations.
Information: the negative reciprocal value of probability. - Claude Shannon