devopsy.kinsta.cloud

Tag: API catalog

Postman Adds Ability to Invoke API Code From Within Git Workflows

Postman today opened its catalog for application programming interfaces (APIs) in a way that makes it possible to manage specifications, collections, tests, mocks, and environments directly from within Git repositories and local filesystems.

Balaji Raghavan, head of engineering for Postman, said that capability provides the added benefit of making it simpler to expose the code used to create an API to an artificial intelligence (AI) agent.

At a time when more software engineering teams are relying on AI tools to write code, making it simpler for AI agents to directly see how the code is used to construct an API without having to invoke an additional tool streamlines workflows, said Raghavan. Instead of having to invoke a separate AI assistant, the intelligence layer that Postman is exposing provides full visibility into specifications, tests, environments, and real production behavior within the context of a Git-based workflow, he added.

According to a recent State of the API Report from Postman, 89% of developers are already using AI. Postman has already developed its own AI agents for designing and building application programming interfaces (APIs), but is now moving to expose its API Catalog to third-party AI agents at a deeper level.

Regardless of approach, the overall goal is to make it simpler for AI agents to select which API to invoke based on the functions exposed in the underlying code while at the same time dramatically reducing the amount of time required to build and deploy an API, said Raghavan.

AI agents, in general, depend heavily on APIs to discover what capabilities exist within an IT environment. The better those APIs are in terms of the quality of the code created and the documentation provided, the more likely it becomes that the code being generated by an AI agent will behave as expected. As such, many organizations will be revisiting how their APIs have been built and deployed in the age of AI, noted Raghavan.

In total, there are more than 40 million developers from 500,000 organizations that are using the Postman platform to create APIs. The depth at which those APIs are managed and secured has tended to vary widely from one organization to another. More than a few organizations have rogue APIs that were documented by developers or zombie APIs that are no longer being maintained but are still accessible. The challenge is that AI agents will discover and invoke any API they find in an IT environment unless specifically trained to only access APIs that are stored in some type of central repository.

It’s not clear how rapidly organizations are adopting AI agents to specifically build APIs, but it’s also only a matter of time before AI agents are routinely called upon to deploy, manage and secure them. In fact, the overall state of API management should improve in the age of API because many application development teams still lack any formal processes for managing them.

In the meantime, however, those same organizations should expect to be building and deploying more APIs than ever in an era where AI agents are going to show a strong preference for invoking services that enable them to easily understand the underlying code.

March 2, 2026
A Funny Thing Happened On the Way to API Management

As API use has exploded across IT departments large and small, the need to manage APIs as independent entities—both APIs themselves and calls to them—rapidly became apparent. We have been through this cycle several times before–ORBs, DCOM, object repositories … the list goes on.

There are several competing goals when introducing some management structure into formerly as-needed remote calls occurs. We want to publish and advertise connections in the hopes we can avoid (or at least minimize) reinventing the wheel, while we also want to make access easier for app developers that are trying to use our APIs. Meanwhile, we want a centralized location where ops can monitor API usage, security can review APIs for compliance and “approved” APIs can be advertised or even hosted. Finally, we want to give internal developers access to approved external APIs that have been deemed appropriate and safe for the organization to use.

As with previous iterations of this process, these goals, taken together, prove to be huge. There is a lot there to try and cover in an ever-changing API landscape. It is worse in this iteration, simply because of the proliferation of external APIs. Prior to REST, each iteration had more APIs, both internal and external, than the one before, and REST is keeping with that pattern, though now that we can look back, the external bit is a hyperbolic curve, not a line.

So, it is interesting and cool to see the market fragmenting a bit. The entire package is a huge order that a few companies have taken on; I’ll leave it to you to decide if they’ve handled it well enough for your org. Others have taken one of two approaches—centralizing API access to external services that have been vetted and interfaced with by the vendor or enabling internal API developers and users.

Now, we have a couple of manageable chunks to look into. I would even go so far as to say most vendors come from one or the other of these worldviews, and you should compare their “tilt” to your organization’s needs before purchasing an API management product. I would much prefer if we separated these markets into ‘API management’–those doing (or trying to do) it all, ‘API integration’–those simplifying and enabling access to approved APIs like Salesforce or ADP and ‘API enablement–those making writing, publishing, securing and advertising internal APIs easier. But I don’t get to make these calls, so we’ll have to watch it unfold.

If your need is to streamline and protect your organization’s access to external platforms, and you use many popular services, start with API integration. If you need to get a handle on APIs that you are creating and using internally, start with API enablement. If you need both, and a centralized store of approved APIs regardless of source, look to API management. APIs have become central to our development efforts, and there will only be more of them in the future, so it is worth deciding where your org could use help and set out to research your options.

Of course, you’re rocking it. DevOPs isn’t letting DEVops poke too many holes in the firewall; DEVops is cranking out solutions and devOPs is keeping them alive. This is just another tool to keep things on an even keel as more and more of the organization’s development is API-based.

June 3, 2021
How to Compare and Contrast APIs to Improve DevOps Processes
The cloud is driving digital transformation, from web applications to mobile applications, from partner integrations to API monetization. Even custom applications are moving into the cloud. If you draw a line through all these trends, APIs would be at the heart of it all.

We know we need to eat our vegetables to keep our heart healthy, but sometimes it is easier to order takeout after a long day of work. Healthy API hygiene works the same way. In a perfect world, developers would register their API specifications and blueprints in an API catalog, and they would keep them up-to-date as the application changes. But this is a tedious manual process, and sometimes after a long day of work it is easier said than done.

An API catalog is critical for improving the DevOps process through quality assurance and testing. Furthermore, the production environment for APIs can be subject to even harsher and more hostile access and usage patterns compared to the Dev and Test environments, which tend to be more self-contained. The good news is that by maintaining an API catalog, DevOps can gain more visibility into the contrast between these environments to identify gaps that should be closed. The end result is an improved DevOps process that drives the production of better products and services.

There are a number of approaches to creating an API catalog, from manually logging APIs into Wikis, spreadsheets and vendor solutions, to more automated discovery tools. An API catalog should include meta information, such as the creator, the date it was last modified, which application it belongs to and so forth. At a deeper level, an API catalog should also include the parameters such as the data type, the bounds for the data type, the transport mechanism, the authentication and authorization mechanism, and a brief description about the data carried within the parameter.

Compare and Contrast APIs from Dev to Test and Test to Production

During the application testing phase, which is subject to quality assurance, regressions, performance and interaction cases, an API catalog should be updated and compared against its development state. The contrast between the development API catalog and those generated from the test environment can help identify:
- An API listed in the Dev catalog, but not in the Test catalog, which would indicate that QA has not tested the API or its payload; therefore, the QA process could be improved.
- An API listed in the Test catalog, but not the Dev catalog, which would indicate that the Dev catalog was incomplete; therefore, you cannot assume it is a “golden” image. This also suggests an area for improvement in the DevOps process because the developer has not maintained an up-to-date API catalog. Automated tools can help even more here since they generate an API catalog where there is none.
There is a third scenario, where an API isn’t recorded in the Dev catalog, and it doesn’t show up in the Test catalog, but may later show up in the production traffic. This is considered an unpublished or “out of spec” API.

Likewise, when moving from test to production environments, the API catalog should be updated to mirror real-world application access. The contrast between the Production API catalog and the Test API catalog can help identify:
- An API listed in the Test catalog, but not the Production catalog, which could identify an API that is not being used. This would indicate that QA testing did not align with the real-world use of the application and suggest that development cycles could be prioritized elsewhere.
- An API listed in the Production catalog, but not in the Test catalog, which would indicate the API catalog did not capture the most up-to-date specification. This is one example of a Shadow API, an API that was intended to be part of the application, but has not gone through the required processes related to testing and application security.
Additionally, identifying an API in the Production catalog, but not in the Test catalog can be useful in identifying threat actors searching for vulnerabilities to exploit an unpublished API.

Comparing and contrasting dev, test and production environments can help identify opportunities for improvement. However, manually creating and maintaining an API catalog is often neglected because of its tedious nature. DevOps needs automated tools to help discover APIs, generate blueprints and store them into the catalog. It is too much of a burden for developers to manually document APIs, but a continuously updated API catalog is the most important key to derive success using the compare and contrast methodology.

— Ravi Balupari
March 24, 2020