The API Evangelist GitHub organization just crossed 10,000 repositories. Each one represents a single API provider — from AWS and Salesforce to federal government agencies, DeFi protocols, academic databases, university library catalogs, and niche vertical tools that most people have never heard of. The question I keep getting asked is: how does a GitHub organization of 10,000 repos become a navigable API network? The answer is an architecture that took me about twelve years to figure out, and it hinges on three things working together — a standard, a catalog, and a set of tooling that treats the standard seriously.

Every Repo Is a Machine-Readable Provider Profile

The unit of the catalog is a GitHub repository named after the provider. Inside every repo, at the root, is an apis.yml file in the APIs.json format (currently v0.19). That file is the source of truth for everything I know about that provider.

It declares the provider’s identity: an aid (a stable, machine-readable identifier), a human name, a description, a set of tags, and a humanURL — the front door. It then lists specific API entries, each with its own properties pointing to machine-readable artifacts: OpenAPI specs, AsyncAPI specs, JSON Schemas. And it carries common properties that cut across all the APIs a provider offers — links to their Plans page, Rate Limits documentation, FinOps pricing data, a JSONLDContext for their vocabulary, and a Blog feed.

The result across 10,000 repos is: 10,754 OpenAPI specs discovered and indexed, 14,123 unique tags, and property coverage that tells me a lot about where the industry has and hasn’t invested. Website coverage across the catalog is 7,836 providers. Documentation coverage is 6,723. Plans coverage is 2,116 — meaning roughly 21% of providers have bothered to publish machine-readable pricing. Rate Limits coverage is 2,295. FinOps is 2,016. Those gaps are as interesting to me as the numbers themselves.

APIs.json Is the Vocabulary That Makes It Parseable

The reason any of this works at scale is that APIs.json is a standard with a defined vocabulary. The property types — OpenAPI, AsyncAPI, JSONSchema, Plans, RateLimits, FinOps, Vocabulary, JSONLDContext, Blog — are not labels I invented for my own crawler. They are standardized terms maintained by API Commons that any tooling can parse without custom logic per provider.

This is the part that most people underestimate when they think about API discovery at scale. The problem is not scraping. I can scrape. The problem is that scraped data has no shared schema, so every consumer has to write a custom parser for every provider. APIs.json solves that by giving every provider the same vocabulary for describing what they publish. When my tooling sees type: OpenAPI in an apis.yml, it knows exactly what to do with that URL — regardless of whether the provider is a two-person startup or a Fortune 500 company.

I started working on APIs.json in 2014 alongside Steve Willmott and others in the community. The goal was always to create a discovery primitive that sat one layer above the API specs themselves — not a replacement for OpenAPI, but an index of where OpenAPI (and everything else) lives. Twelve years later, with 10,000 repos all carrying an apis.yml, I feel like that bet paid off.

The Standards Layer Is the Governance Layer

One thing that took me longer to articulate is that the catalog is not just a discovery artifact — it is also a governance artifact. When I add a JSONSchema property to a provider’s apis.yml, I am capturing their data model in a machine-readable format that any downstream consumer can validate against. When I add a Vocabulary property, I am anchoring their domain terms. When I add a JSONLDContext, I am connecting their data structures to the linked data web.

These are not decorative. The Standards layer of the catalog — the combination of JSONSchema, Vocabulary, JSONLDContext, and Plans/RateLimits/FinOps — gives me the raw material for governance tooling. I can ask questions like: which providers in the Healthcare tag have published a JSONSchema for their data models? Which providers in the Financial Services category have machine-readable pricing? Which government agencies have a Vocabulary that other agencies could reuse? The apis.yml in each repo is the hook I use to answer those questions programmatically, across 10,000 providers, without manual lookups.

This is why I put so much energy into the property coverage numbers. Every gap in the coverage map is a place where the industry has not yet invested in making itself legible to machines. The 78% of providers without machine-readable Plans are not bad actors — they just haven’t been asked to publish that data in a format tooling can consume. The catalog makes the ask visible.

How It Feeds APIs.io

The GitHub repos don’t just sit there. They feed APIs.io, the search and discovery layer I maintain on top of the catalog. The crawler reads every apis.yml, indexes the provider identity, the API entries, and the properties, and surfaces them through a search interface organized around 14,123 unique tags.

That tag vocabulary is one of the most useful artifacts to come out of the catalog work. Tags in apis.yml files are freeform — providers contribute their own terms — but over 10,000 repos, patterns emerge. The top tags tell me which categories of the API economy are most active. The long tail tells me where the catalog still has gaps. And because tags are indexed and browsable at tags.apis.io, they give both humans and agents a structured entry point into the network without needing to know what specific provider they’re looking for.

The result is that what started as a personal blog about the API economy has become infrastructure. The blog is still there — this post is part of it — but underneath it is a machine-readable catalog of the providers I’ve been writing about for sixteen years. The stories and the structured data are built on the same foundation, which is exactly how I wanted it to work when I started sketching this out in 2014.

Why GitHub as the Storage Layer

Using GitHub as the backbone of the catalog was a practical decision that turned out to have real structural benefits. Git gives me version history on every apis.yml — I can see when a provider added Plans coverage, when their OpenAPI URL changed, when they picked up a new tag. GitHub’s API gives me programmatic access to the catalog without maintaining my own storage infrastructure. And the public nature of the organization means anyone can open a pull request to correct a provider profile, add a missing spec URL, or flag an outdated property.

The catalog is not a database I maintain in isolation. It is a public, version-controlled, community-editable index of the API economy, structured around an open standard. That combination — open standard, public repo, Git history — is what lets me hand it off to tooling, to agents, to other researchers, and have some confidence that they’re working from the same source of truth I am.

Ten thousand repos. Sixteen years of work. One apis.yml at a time.

I feel that last part is worth thinking about more. The word monetization has always been a barrier in exactly the places where API value matters most. When I was pushing the Department of Agriculture to make APIs a first-class citizen in the Recreation One Stop RFP, I couldn’t walk into those rooms talking about monetizing access to campsite reservations or national park geospatial data. The value was real — millions of families planning camping trips, small businesses building itinerary tools, agencies making operations data portable and interoperable across the Forest Service, Army Corps of Engineers, Bureau of Reclamation, and a dozen other federal partners — but the word “monetization” shut the conversation down before it started.

I have been using public lands as an analogy for public data APIs for years because of this. A national park isn’t valuable primarily because it generates revenue. It’s valuable because of what it makes possible: recreation, conservation, ecological research, local economies, a shared sense of what this country is. The value is real, diverse, and distributed across many stakeholders — not all of whom are in a financial relationship with the park service. The same is true of a well-designed public data API. Calling the question “how do we monetize this?” misframes what’s actually happening, which is an exchange of value — in many different directions, not all of them financial.

I want to start calling this what it is: API value exchange.

AI has given me renewed energy for this framing. Not because AI makes APIs more commercial, even though it often does. It is because AI has made the volume and velocity of API consumption so undeniable that even organizations that spent a decade ignoring the question can’t look away anymore. As I have been writing lately, there is really only API consumption — everything else is scaffolding in service of getting value from one system into another. AI agents are now doing this at a scale and speed that exposes every gap in how organizations have been thinking about the value flowing through their APIs. The question is no longer whether to think about API value exchange. It is whether you have built the visibility to see it happening.

The renewal I’m feeling is not about AI APIs specifically — the market for those is being worked out loudly and publicly enough. What interests me is how AI-driven consumption is forcing organizations to think carefully about their internal APIs, their partner APIs, and their public APIs simultaneously, often for the first time. These three tiers have always existed. What’s new is the market pressure.

Internal API consumption is where the question gets ignored most often, and where it matters most. I wrote about this more than a decade ago when I was figuring out my own API stack — the first consumer of my APIs was me, and I needed to track that usage the same way I tracked any external consumer. Not to bill myself, but to understand the costs, identify unhealthy consumption patterns, and see the full picture of what was flowing through the system. Instagram and Tesla learned this the hard way; their internally-consumed APIs had no management layer, which meant attackers could walk through doors nobody was watching.

In the AI era, internal API consumption is exploding. Every agent, every automated workflow, every LLM-powered feature in your product is an API consumer. Many of these are consuming the same internal APIs that your engineering teams built to serve each other. The value exchange happening at this layer — between your AI infrastructure and your business capabilities — is now significant enough to warrant governance, cost accounting, and visibility. Not because you’re going to charge your own teams, but because you cannot manage what you cannot measure, and the costs are real.

Partner API consumption is where the value exchange framing does its most useful work. A financial relationship is often present here, but it is rarely the whole story. When I worked on the Recreation.gov RFP, the valuable thing about building a partner API layer wasn’t the per-transaction fees — it was enabling travel planning companies, outdoor recreation apps, and small regional businesses to build on top of federal recreation inventory in ways the government could never staff or fund directly. The value flowing back wasn’t money; it was reach, adoption, feedback, and services delivered to citizens that the government couldn’t deliver itself.

Partner APIs are how organizations extend their capabilities beyond what they can build alone. In the AI era, this is even more true. Your partners are now building AI agents that consume your APIs to automate workflows, extract insights, and create new customer experiences. The terms of that exchange — who gets what value, what obligations come with access, how abuse is prevented — need to be explicit. This is what service composition means in practice: understanding your API consumers well enough to design the tiers of access that make the exchange fair and sustainable for everyone in it.

Public API consumption is where the public lands analogy remains the most useful in my opinion. The value of making an API public is almost never primarily financial. It is about ecosystem, discoverability, innovation at the edges, and — in the government context — fulfilling a public mission that data belongs to the people who funded its collection. The question I was wrestling with in 2015 — are there any monetization opportunities around open data and APIs — was a real one, but it was the wrong frame. The question should have been: how do we make the value of this data visible enough to fund its continued maintenance and improvement?

Revenue can be part of the answer. Charging high-volume commercial consumers while keeping access free for researchers, nonprofits, and individual developers is a reasonable model, and one that several government API programs have moved toward. But the goal isn’t to monetize the data. The goal is to sustain the exchange — to keep the data good, keep access open, and grow the ecosystem of things that get built on top of it. That is what public API value exchange means.

I have been at this long enough to know that the hard part is never the framing. Calling it “API value exchange” instead of “API monetization” is only useful if it opens conversations that the other word closed. In government, where I have done some of this work, it does. In enterprise settings, where internal teams are being asked to justify API spending to leadership who didn’t prioritize APIs until AI forced the question, it also helps. In the public data world, where agencies are trying to figure out how to sustain open data programs that are politically popular but chronically underfunded, the value exchange frame gives you something concrete to point at.

The mechanics of this are service composition, rate limits, plan design, cost accounting, partner agreements — haven’t changed much since 2015. What has changed is the urgency, and the volume. AI has cranked up the consumption signal loud enough that the exchange is now impossible to ignore. I intend to spend more time on this framing going forward, connecting the decade-plus of thinking I’ve done on monetization to the reality of what is actually happening at the intersection of AI and APIs right now.

API Evangelist began as an idea in July of 2010, and took form in the first series of blog posts published in September of 2010. At the time I lived in Eugene, OR, had just gotten together with my girlfriend and now wife Audrey Watters. I was looking to move on from a job as VP of Technology at an events management company who was running SAP and Google events in North America. APIs were something I had experience with and seemed interesting.

While running events I had begun to use AWS S3 and EC2 to help me manage the servers I needed for registration, emails, session scanning, and other common conference tasks. In the early days of AWS there weren’t a lot of applications and tools, so I got pretty skilled at working the kung fu I needed to stand up and tear down the servers I needed to support email blasts and the first day of a conference. When I took over the role I had to physically go pull servers out of a storage unit, drive them to the colo facility, and physically install the software I needed. I didn’t have a lot of room for scaling up and down as needed to meet the demand. The cloud changed that, and I saw APIs were a key part of the process.

In 2008 I was running registration for Google I/O, and it was the one where they first launched the Android phone. At the time it was literally a phone they manufactured, as well as the operating system, and every attendee got a phone. Google pushed us to build applications and integrations around their APIs, including Google Wave. Remember Google Wave? This opportunity gave me another chance to see the potential of developing with scrappy, lightweight XML or JSON APIs over HTTP. The need for data and other digital resources over iPhone and now Android lit the fire underneath me — seeing the potential for using HTTP APIs to do everything from the cloud to mobile, forever changing my life and career.

By 2009 I was ready to move on from the event space and began looking for jobs that were related to APIs. I took a brief job with Mimeo, a print company in NYC, and CityGrid, a city data provider in West Hollywood. I used this opportunity to learn more about operating public APIs and portals, and settled on the brand “API Evangelist”, emulating Guy Kawasaki and Jeff Barr, but with an exclusive focus on APIs. At the time I was programming, but I was a pretty insecure programmer with no classical training. So I focused on what I considered to be the business of APIs, instead of the technical details, hoping to build bridges with business stakeholders when it came to what mattered when doing public APIs. The concept of internal APIs wasn’t such a big thing, and was mostly dominated by the concept of service-oriented architecture. But public APIs were exploding with the introduction of Facebook and Twitter, as well as Twilio and Stripe.

At the same time my girlfriend Audrey was looking to establish herself as a writer, and chose to focus on Hack Education. She has her masters in folklore and storytelling, which provided the seed of inspiration for my focus on storytelling around APIs. Pausing to write this story, not a lot has changed. I’ve added the politics of APIs to the mix, and I’ve gotten much more confident in my technical chops when it comes to APIs. Storytelling is really the only thing that keeps me going with this work. I love listening to people’s stories about what they do with APIs, and I really enjoy sitting down to write stories about what I’ve heard and learned. I am thankful for the opportunity to publish 5000+ stories here, and the many, many, many conversations I’ve had with people doing interesting things with APIs over the years. It has been an amazing journey, and honestly I can’t see myself ever putting it down, and I hope I can keep it up until the day I step out of this world. I don’t see ever retiring from learning and telling stories about APIs.

The diagram above is my current read on the toolbox. Every time someone tells you that REST is dead, or that everything will be GraphQL, or that MCP will replace all your APIs, remember: they are a tool salesperson, not a practitioner. The people who get things done across the real enterprise have a diverse set of tools and know when to reach for which one.

API Design Patterns

These are the request/response patterns — the core of how clients talk to servers.

• REST is still the dominant pattern and will remain so. It maps cleanly to the web, it is simple enough that a wide audience can consume it, and it has the broadest tooling support. Every practitioner should be able to design and ship REST APIs well. The limitations are real — deep queries, real-time data, tight coupling between client and server — but none of them mean REST is going away.
• GraphQL earns its place when consumers need to drive the shape of the response. Data-intensive products, mobile clients, and cases where you want to avoid under/over-fetching are where GraphQL genuinely shines. It also moves the schema front-and-center, which I respect. The tradeoff is complexity on the server and a higher floor for client sophistication.
• gRPC is the two-speed API. When you need high-volume, low-latency inter-service communication inside a data center or across microservices, gRPC’s binary Protocol Buffers wire format and HTTP/2 multiplexing make a meaningful difference. It does not belong as your public-facing API unless your consumers are large enough to justify it — but it absolutely belongs in the toolbox.

Event-Driven Patterns

The moment your architecture needs to react to something happening rather than being polled for information, you reach for event-driven patterns. The mistake is treating any of these as a full replacement for request/response. They are complementary.

• Webhooks are the simplest push pattern: when something happens, HTTP POST to a URL the consumer registered. Stripe has built their entire developer experience around webhooks. They are asynchronous, decoupled, and nearly universal. Every API platform should offer webhooks before it offers Kafka.
• Event Destinations is the more mature form of webhooks — where instead of just delivering to a URL, you deliver to configurable targets: S3 buckets, queues, other APIs, third-party services. Stripe, GitHub, and Shopify have all converged on this model. It shifts integration work from bespoke webhook receivers to a routing problem, which is much more tractable at scale.
• WebSockets open a persistent bidirectional connection. This is for genuinely real-time interactions — chat, live dashboards, collaborative editors, trading feeds. The connection overhead is real, so this is not the right tool for fire-and-forget notifications. Know the difference between “low latency” and “real-time” before you reach for WebSockets.
• Kafka is industrial-grade event streaming. When you are moving millions of events per second, need replay capability, need durable ordered delivery across many consumers, and need to run at scale across distributed infrastructure — Kafka (and its ecosystem) is the answer. Too many organizations reach for Kafka before they have exhausted simpler patterns. It is powerful and it is complex. Make sure you can operate it reliably before you commit.

Experience Patterns

These are the patterns that determine whether your API actually gets used. You can ship a technically perfect API and have zero adoption if the experience around it is poor.

• Documentation is not optional. It is the interface between your API and your potential consumers. The bar in 2026 is an interactive reference generated from OpenAPI or AsyncAPI, supplemented by guides that explain how to actually accomplish something with the API rather than just enumerating its endpoints. If your documentation is just a list of routes, it is not documentation — it is a changelog.
• Mock Servers close the loop between design and development. Consumers should be able to start building against a mock before the real implementation exists. Prism, Mockoon, WireMock — the tooling is mature. If your team cannot create a mock server from an OpenAPI spec in an afternoon, something is wrong with your process.
• Discovery is the increasingly critical, chronically underinvested pattern. Can your developers find every API available to them? Can an AI agent? I run APIs.io specifically because API discovery is a genuinely hard problem that affects everyone doing API integration at scale. APIs.json and well-maintained developer portals are where this gets solved.

Integration Patterns

How do consumers actually wire your API into their systems?

• Clients are the generated or hand-crafted HTTP client code that wraps the raw HTTP calls. A good client handles authentication, retries, rate limit backoff, and pagination. Auto-generating clients from OpenAPI specs has become table stakes — if you are not generating client libraries, you are creating unnecessary friction.
• SDKs go beyond clients to provide a higher-level abstraction that fits a specific language’s idioms. The Stripe SDK for Python feels like Python, not like a thin wrapper around HTTP. The gap between a good SDK and a generated client is the difference between adoption and abandonment.
• Copilots are the AI coding assistants — GitHub Copilot, Claude, Cursor — that now function as first-line integration support. They are only as good as the machine-readable artifacts they can access. An API with a well-structured OpenAPI spec, good descriptions, and examples is vastly more useful to a copilot than one with none of those things. Writing for copilots is writing good API documentation.
• Agents are the autonomous systems that compose multi-step API calls to accomplish goals without human intervention in each step. This is where MCP and Agent Skills directly feed in. An agent needs to discover what APIs exist, understand what they do, and be able to call them safely and reliably. The toolbox patterns connect: REST and gRPC for the calls, OpenAPI for the contract, MCP as the agent-native access layer.

AI Patterns

These are new tools in the toolbox as of the last two years, and while they dominate much of the conversation, they are beginning to shrink back down to a realistic cope in our modern toolbox.

• MCP (Model Context Protocol) is Anthropic’s open protocol for how AI models access tools, data, and services. What started as a way to wire Claude into local development environments has become a standard that Microsoft, Google, and hundreds of API providers have adopted. An MCP server exposes your API’s capabilities as tools that an AI model can call directly — with proper auth, schemas, and descriptions. I have been cataloging which providers in my network ship MCP servers. The number growing fast.
• Agent Skills (SKILL.md) are structured definitions that describe what an agent can do in a portable, discoverable format. Where MCP defines the protocol, a skill definition describes the intent, inputs, outputs, and preconditions of an agent capability. I have been building this out as part of the Naftiko work. Skills allow agents to compose and delegate in principled ways rather than through freeform instruction.

The important thing to understand about MCP and Agent Skills is that they do not replace REST, GraphQL, or any of the other patterns. They sit on top of them. An MCP server typically calls REST APIs internally. An agent skill may orchestrate a sequence of Kafka events and REST calls. The foundation does not go away — you are extending the toolbox, not replacing it.

Media Types

One of the things I keep having to remind people: the format your API returns is a design decision with real consequences for who can use your API and how.

• application/json — the lingua franca; assume JSON unless you have a specific reason not to
• application/xml — still required in enterprise, government, and healthcare integrations; do not pretend it does not exist
• application/yaml — human-readable and increasingly expected for configuration, specs, and anything a developer will edit directly
• application/csv — underestimated; a CSV response from a data API means a non-developer can open it in Excel; never underestimate the spreadsheet audience
• application/html — your API responds with HTML; this is both older than REST and more prevalent than most API designers acknowledge
• text/markdown — increasingly relevant as LLMs consume API documentation; structured natural language that both humans and models can read

Negotiating the right media type is something your toolbox should handle gracefully. An API that can return application/json when asked and application/csv when asked is strictly more useful than one that can only do one.

API Specifications

Machine-readable contracts are the connective tissue of the entire toolbox. Without them, nothing else scales.

• OpenAPI remains the primary contract format for REST APIs. 23,000+ specs indexed on apis.apis.io. The tooling ecosystem is enormous. If you are building a REST API and not shipping an OpenAPI spec, you are intentionally making integration harder.
• AsyncAPI does for event-driven what OpenAPI does for REST. Kafka topics, WebSocket channels, webhooks — AsyncAPI describes them all in a consistent machine-readable format. It remains underinvested relative to its importance.
• JSON Schema is the data modeling layer that both OpenAPI and AsyncAPI build on. Used directly for validating JSON payloads, generating documentation, and providing type-safe contracts. 95,000+ schemas indexed in my network.
• GraphQL SDL is the schema definition language for GraphQL APIs — self-documenting, introspectable, the reason GraphQL has the tooling ecosystem it does.
• MCP Spec defines MCP server capabilities in a machine-readable format — what tools an MCP server exposes, their inputs and outputs, how to auth. The spec is young but stabilizing fast.
• Agent Skills specification is still evolving. The goal is a portable, platform-agnostic format for describing what an agent can do — composable, discoverable, and grounded in the underlying APIs that make the skills work.
• Protocol Buffers is the schema format for gRPC — binary, strongly typed, backward compatible. If gRPC is in your toolbox, Protocol Buffers comes with it.

The lesson from every API cycle — REST, GraphQL, webhooks, Kafka, and now MCP — is that the practitioners who succeed are not the ones who pick the pattern that gets talked about the most. They are the ones who understand the tradeoffs of each tool, know when to reach for which, and can explain those choices to the people around them. The future is not event-driven. It is not AI-native. It is not any single thing. The future is having a diverse API toolbox and knowing how to use it.

That is the message I keep coming back to. That is the message APIDays Amsterdam keeps reinforcing. Maintain your diverse API toolbox and understand where new tools being discussed fit in.

The answer: five. Cognite, Limble CMMS, Inductive Automation’s Ignition, Factory I/O, and Formant. Five out of 56 providers that I explicitly selected because they sounded like they had APIs.

That number tells a story worth unpacking, because AI agents need industrial data, the industrial data lives behind systems that don’t always speak REST, and the gap between those two facts is where the next wave of manufacturing AI integration is either going to break through or break down.

What the vocabulary tells you

Before I get into the AI angle, let me walk through what the tag vocabulary across those 421 providers looks like. The top tags paint a picture of where the industry thinks its API surface lives:

The big buckets — Manufacturing, Industrial, Supply Chain — are describing what the company does, not what their API surface is. Dig into the more specific operational tags — SCADA, MES, CMMS, PLM, PLC, OPC UA — and the count drops fast. Most companies in this space are not primarily API providers. They are equipment makers, systems integrators, specialty chemical producers, and industrial conglomerates that happen to have some integration capability somewhere in their stack. That distinction matters a lot once you start asking what an AI agent can actually connect to.

The three layers of the industrial API stack

After cataloging all of this, I think the industrial manufacturing API landscape has three reasonably distinct layers, and each has a different relationship with AI integration.

Layer one is the industrial data platform — Cognite Data Fusion, AVEVA PI (formerly OSIsoft), Siemens MindSphere, Rockwell FactoryTalk DataMosaix. These are the systems that already aggregate time-series sensor data, asset hierarchies, events, and process historian records from the operational technologylayer and make them available over REST. Cognite is the best example: a comprehensive API covering assets, time series, 3D models, entity matching, SQL transformations, serverless functions, and workflow orchestration. It has a proper OpenAPI spec, Python and JavaScript SDKs, and the architecture of a company that treats its API as a product. AVEVA PI similarly exposes a Web API with GET/POST/PUT/PATCH/DELETE operations against historian data. These are the providers where an AI agent can actually do something useful today — they have already solved the hard problem of getting operational technologydata into a form that REST can address.

Layer two is the manufacturing operations platform — Tulip Interfaces, Rockwell Plex ERP, Epicor Kinetic, Inductive Automation’s Ignition. These sit on or just above the shop floor and manage the operational data that flows through a production run: apps, tables, stations, work orders, quality records, jobs. Tulip has a genuinely clean REST API organized into namespaces — apps, table records, connectors, stations, automations — each independently versioned. Ignition 8.3 now exposes an OpenAPI-compliant gateway API for tag reads, project configuration, and module access, which is a significant signal: SCADA is starting to grow an HTTP surface. Epicor Kinetic exposes everything through OData v4, which is not REST in the way most developers think of it, but it is machine-addressable and has an interactive spec explorer. This layer is where the AI integration story gets genuinely interesting, because it is where the human decisions and production instructions actually live.

Layer three is the maintenance and asset management layer — CMMS systems like Limble, Fiix (now Rockwell’s), and UpKeep; EAM platforms; condition monitoring vendors like Augury. Limble has one of the cleanest manufacturing APIs I encountered in this exercise: a proper REST API with regional endpoints, Basic auth, and resources covering assets, locations, work orders, preventive maintenance tasks, parts, purchase orders, vendors, and webhooks. It even has a 21 CFR Part 11 compliant endpoint for pharmaceutical manufacturing. UpKeep is similarly solid. This layer is interesting for AI because it holds the maintenance history, failure modes, part lifecycles, and work order patterns that predictive maintenance models need to learn from.

The operational technology floor is still not on the internet

Below all three of these layers sits the actual operational technology — PLCs, DCS systems, SCADA historians, CNC controllers, field instruments, vision systems. This is where the physical manufacturing happens, and almost none of it speaks REST natively. The protocols are OPC UA, Modbus, PROFINET, MTConnect, EtherNet/IP — industrial protocols designed for deterministic real-time control over hardened networks, not for cloud-native HTTP integrations.

The pipeline run I did confirmed this in clear terms. ABB Robotics: no public API spec, developer documentation is proprietary and gated. FANUC Robotics: no public API, MTConnect adapter available but not REST. KUKA: no public API surface. Honeywell: portal exists, no published spec. Bosch: IoT Suite exists, all probe paths returned 401 or redirects. Boston Dynamics: gated SDK, no REST spec. Yaskawa: application programming interfaces exist for servo controllers, no REST spec.

These are not small companies. These are the companies that build the machines that make almost everything you touch. And the gap between “has some form of API” and “has a publicly discoverable, machine-readable API spec” is enormous in this space.

Why this matters for AI agents right now

The current wave of agentic AI is fundamentally a data access problem. An agent is only as useful as the data it can read and the actions it can take. In most enterprise verticals — SaaS, fintech, logistics, healthcare IT — that problem is largely solved because the cloud-native players built REST APIs as their primary interface. An AI agent can hit Stripe, Plaid, Salesforce, Workday, or any of ten thousand other providers and get back structured JSON that it can reason over.

Manufacturing is different. The most important data in a manufacturing operation — real-time sensor readings, production counters, OEE metrics, alarm histories, quality inspection results, tool wear measurements — lives in systems that predate REST by decades and were designed to be isolated from enterprise networks on purpose. The industrial security model treats network isolation as a feature. The AI integration model needs the opposite.

The forward-looking industrial players are bridging this with industrial data platforms as the translation layer. Cognite’s entire value proposition is exactly this: take operational technology data from historians, SCADA systems, and sensors via industrial connectors, contextualize it into a data model that exposes assets, time series, and relationships, then make all of it available over a well-documented REST API. When Cognite and Tulip announced their integration partnership, the stated goal was a 45% increase in production capacity driven by AI — made possible because Cognite’s data fabric connects the operational technologysensor layer to Tulip’s operator-facing applications, and both expose REST APIs that an AI agent can work with. That partnership is a preview of how the integration stack for industrial AI actually needs to be assembled.

The SCADA OpenAPI signal

One of the more interesting findings from this exercise was Inductive Automation’s decision to add an OpenAPI-compliant REST API to Ignition 8.3. Ignition is the dominant SCADA platform for mid-market and enterprise manufacturing — tens of thousands of deployments across water treatment, food production, oil and gas, discrete manufacturing. It has always been deeply extensible through Python scripting, OPC UA, MQTT, and a module ecosystem. Adding an OpenAPI gateway that documents tags, projects, device connections, and module routes as REST resources is a meaningful shift.

It is not cloud-native REST in the Stripe sense. The base URL is https://{gateway-host}:8088/api — this is a local or on-premise gateway, not a SaaS endpoint. But the fact that the spec is generated dynamically from installed modules, is OpenAPI 3.0 compliant, and logs all mutative operations to audit trails means it is now a surface that integration tools and AI agents can discover and address programmatically. That matters. The question of how an AI agent talks to a SCADA system is a question that has not had a clean answer until now.

What is still missing

The honest assessment is that the industrial manufacturing API space has most of the pieces and almost none of the connective tissue.

The industrial data platforms exist and have good APIs. The operations platforms are growing REST surfaces. The CMMS layer has mature APIs. The operational technologyequipment layer has industrial protocols and some modern adapters. What is almost entirely absent is:

Standardized schemas. OPC UA has an information model, MTConnect has a schema, but neither maps cleanly to what a REST API returns. There is no manufacturing equivalent of the FHIR standard in healthcare — a common data model for production orders, quality records, equipment states, and maintenance events that every vendor agrees to. Every provider defines their own object model, which means every integration has to be built from scratch.

Publicly discoverable specs. Of the 56 most API-forward industrial providers I examined, only five had a spec I could find through normal discovery paths. That is not necessarily because the APIs do not exist — some do — but because the culture in industrial software treats API documentation as a competitive asset to be gated behind enterprise sales conversations rather than published on a developer portal. Cognite and Limble are outliers in treating their specs as open, discoverable artifacts.

Agentic tooling designed for operational technology constraints. The AI agent frameworks being built today — LangChain, the Anthropic tool-use ecosystem, Microsoft’s Semantic Kernel — assume REST APIs with JSON responses and short latency. Industrial systems have real-time constraints, safety interlocks, and data rates that do not fit those assumptions. An AI agent that misreads a latency spike as a sensor failure and triggers a SCADA alarm is worse than no agent at all. The interface standards for AI agents interacting with operational technologysystems safely have not been written yet.

The decade ahead

The MES market is at $15.2 billion today and projected to reach $28.5 billion by 2030. OT/IT convergence is accelerating — BCG estimates adoption of converged IT/OT infrastructure for new manufacturing projects will go from roughly 10% to 50% within five years. The manufacturing sector is moving from static dashboards to what the industry is calling agentic AI: systems that can perceive plant conditions, reason over historical data, and take action through the control layer.

All of that requires APIs. The industrial data platforms are ready. The operations layer is getting ready. The operational technologyfloor is being connected, layer by layer, through industrial IoT gateways, MQTT brokers, OPC UA aggregators, and — increasingly — REST wrappers.

What I cataloged in the API Evangelist network this week is a snapshot of where this transition stands in mid-2026. 421 providers touching the manufacturing space, most of them describing themselves in terms of what they make rather than what their integration surface looks like. Five publicly discoverable OpenAPI specs out of the 56 most API-facing providers I examined. A handful of companies — Cognite, Tulip, Limble, Inductive Automation — who have figured out that treating the API as a product is how you become the integration layer for the next generation of manufacturing intelligence.

The gap between those five and the other fifty-one is where the real work of industrial AI integration will happen over the next decade. The factory floor has an enormous amount of data. Getting it into a form that an AI agent can reason over is the hard problem, and the API surface is where it gets solved or does not.

All provider data is from the API Evangelist network catalog, enriched as of June 2026. Pipeline results reflect publicly discoverable OpenAPI specifications only — many providers have gated or proprietary API documentation not captured here.

The answer to that last question reframes the whole exercise. Across those 219 schools I cataloged 634 APIs spanning 40 countries, and the overwhelming majority of them exist for one reason: the university library runs an institutional repository, and that repository speaks OAI-PMH. 84% of these universities (185 of 219) expose a repository or OAI-PMH style API. Only 16% (35 of 219) run anything that looks like a modern developer program — a portal, OAuth, a gateway, an open-data API. The world’s best universities are sitting on an enormous amount of structured data and have almost no front door to it.

Where the universities are

Europe dominates the profiled set, which tracks with how QS weights its rankings:

By country, the United States leads with 39, then the United Kingdom (27), Australia (16), Germany (12), Canada and the Netherlands (11 each), China and Japan (9 each), and Switzerland (7). Australia massively over-indexes for its size — sixteen schools — and the Netherlands punching at eleven is a reminder that the Dutch have treated research data as public infrastructure for a long time.

What a “university API” actually is

Here are the most common API tags across all 634 APIs. Read this list top to bottom and the story tells itself:

• Repository (205), OAI-PMH (205) — the Open Archives Initiative Protocol for Metadata Harvesting. This is the plumbing search engines and aggregators use to harvest a library’s catalog.
• Research (185), Metadata (170), Open Access (148), Open Data (142)
• Library (135), Research Data (98)
• REST (84) — only now do we get to the thing most people mean when they say “API.”
• DSpace (76), Institutional Repository (60), EPrints (28), Dataverse (24), Pure (21), Figshare (19) — the repository platforms themselves.
• Identity (68), Authentication (66), SSO (47), Shibboleth (30), SAML (30) — campus single sign-on, mostly federated through the academic identity systems.
• Education (51), Courses (33) — course catalogs and timetables.

So the typical “API” at a top university is not a developer product. It is a metadata harvesting endpoint that a librarian stood up — or more likely that came bundled with DSpace, EPrints, Figshare, Dataverse, or Pure — exposing the institution’s research output to the world. That is genuinely valuable, machine-readable, and open. It is also almost never documented, versioned, or framed as something a developer should build on.

The schools doing the most

Counting raw API surface, here are the leaders:

What separates the top of this list is that a few of these schools went past the repository and built a real developer surface.

UCL is the clearest example of a university that operates like an API provider. Its UCL API program publishes Room Bookings, Timetable, Search, Workspaces, and Resources endpoints behind a proper OAuth flow — built largely by and for students, but a legitimate developer portal. That is what a university developer program looks like, and almost nobody else has one.

University of Pennsylvania is the other standout: a Penn OpenData API, official Penn SDKs in Python and Node, a Penn Courses (PCX) API, and a Penn Course Review API. Again, much of this grew out of student developer culture, but the result is a usable, SDK-backed surface.

UC Berkeley is the institutional version of the same idea — “API Central,” an actual developer portal, sitting in front of a UC Berkeley API Gateway, plus the eScholarship repository and Alma/Primo library integrations underneath.

The interesting corners

The fun is in the outliers — the APIs that aren’t just another repository harvest endpoint:

• Caltech exposes the IRSA Virtual Observatory APIs through IPAC — astronomy data infrastructure, which is exactly the kind of thing you hope a place like Caltech puts on the open web.
• ETH Zurich has the most interesting library surface of the bunch: a Geo Information API, a Persons API, a Vector API, and ETHorama alongside the expected Research Collection — the Swiss treating the library as a data platform.
• Shanghai Jiao Tong University publishes a Data Resources GraphQL API — the only GraphQL surface I saw in the entire set, and notable for coming out of mainland China.
• EPFL runs a Memento Events API — campus events as a feed.
• Columbia exposes a CU Directory of Classes, and NUS has the community-built NUSMods API (unofficial, but the most-used student API in Singapore).

And the repository platforms read like a who’s-who of scholarly infrastructure: DSpace at NUS (ScholarBank), EPrints at Southampton (which is fitting — EPrints was born at Southampton), Figshare at the University of Hong Kong, Dataverse at NTU, Pure at Edinburgh, and Alma/Primo at Berkeley.

What this tells me

Universities are not behind on APIs in the way most enterprises are. They are behind in a different way. A Fortune 1000 company usually has the developer program and is missing the open data. The top universities have the open data — enormous, structured, machine-readable research output — and are missing the developer program. The data is already there, already public, already speaking a standard protocol. What is almost entirely absent is the front door: documentation, a portal, OAuth where it is needed, and the basic acknowledgment that the OAI-PMH endpoint a librarian configured a decade ago is, in fact, an API that someone could build on.

The schools at the top of my count — UCL, Penn, Berkeley — figured this out, and in every case it was the institution choosing to treat its data like a product. The other 184 are one developer portal away from being genuinely useful to the outside world. The plumbing is already in the walls.

Profiled from the QS World University Rankings 2025 set in the API Evangelist network. Counts reflect what I have cataloged, not necessarily every API each school operates; a handful of entries (like NUSMods) are community-built rather than official, and are flagged as such in the profiles.

I am not one to be deterred, and usually will find a way to get what I want. I finally did. You don’t have to be a programmer to do this, but you have to be technically brave. Another caveat and assumption. I use the Claude VSCode extension to do this, which gives you more file-level access to many files—which transforms how you use Claude. I highly recommend it, even if you aren’t a programmer. Like GitHub, you don’t have to write code to use VSCode—it is just an editor. I don’t have the time right now to work out all the details using Claude desktop, web, or via ChatGPT or Gemini—if you need that, let me know, maybe sweet talk or pay me, and I may be able to prioritize one of these solution paths. Let me know.

Fiddler Everywhere

This journey begins with downloading Fiddler Everywhere, a modern, cross-platform web debugging proxy and traffic analyzer available for Windows, macOS, and Linux. It captures, inspects, mocks, and modifies HTTP and HTTPS traffic between your machine and the internet.

Turn it on and capture all traffic. Again, you don’t have to be a programmer, but you need to be technically unafraid, and it is a tool that will open up a whole new world for you if you do. It is a gateway drug to APIs, and you will see the digital world differently once you get acquainted with it.

LinkedIn

Once you’ve downloaded and installed Fiddler Everywhere, open it up and you will immediately see traffic from across EVERY website you visit, and everything behind it flowing through Fiddler. Now visit LinkedIn. Spend some time browsing through all of the types of data you wish to capture. Here is a list of the LinkedIn entities I browse to get what I needed.

• Posts - Posts I submitted or shared. I try to stay off the home page.
• Reactions - Opening up the full list of reactions to each post.
• Profiles - Clicking open the profile pages of people I am interested in.
• Messages - Opening up messages, replying, and scrolling up and down.
• Groups - Opening up the groups I manage or am part of and scrolling down.

Fiddler will only record what you load, so scroll around, click and load what you want. Stay off the things you don’t want. I recommend staying in your notifications, mentions, and groups, but you can open up the profile of people you want to “profile” and view their page and activity. I regularly use this to find out what people are interested in, by gathering what they have posted and what they have shared.

Filtering

Once you are done exploring LinkedIn and are ready to process your activity for the day or any given moment, maybe after research, click on the filters button in Fiddler, and add a URL Contains filter for https://www.linkedin.com. It will list all of the traffic just for LinkedIn. Highlight everything by hitting command or control all, right click and choose export RAW file. Put it somewhere you remember, so you can direct Claude to it via a path you will need to update via the Agent Skill I have provided below.

This is a process you can do for any website. It isn’t limited to LinkedIn, but the Agent Skill I provide is only for LinkedIn. The same approach will work for any website or application you use, but the entities you capture will be relative to the platform. It just depends on what you capture and are looking to mine. This is what makes Fiddler so powerful. You can leave it on all day and paint a picture of your entire digital footprint. Warning though, there are some sites where having a proxy open will screw with things, so be aware. I leave it on all the time and then a website doesn’t load or I get wonky things.

Agent Skill

I have created an Agent Skill to guide each time I do this, and I am happy to share it with you. I’ve pasted it here via a GitHub Gist, but you will need to download it locally and edit it. You will need to update the [local path] location which exists throughout the skill with the local path where you save your Fiddler RAW file containing all your LinkedIn traffic. Make sure to read the entire Agent Skill. Again, you don’t need to be a coder to do this, it is plain enough English that you should be able to follow. NEVER trust an Agent Skill file from anyone—even me. It is easy to put malicious things in there that can mess with your world.

I save the Agent Skill to the .claude/skills folder in the project I have VSCode open to, which I then save my Fiddler file to social/linkedin/*—you will have to navigate this on your end, and update the path accordingly. Like I said earlier, if you want to do this via Claude desktop, web, or Gemini and ChatGPT, it is a separate process, but the same approach and skills will work, but the file system voodoo will vary.

Here is the full Agent Skill (you can also download the raw file from the GitHub Gist):

---
name: parse-linkedin
description: Parse a Fiddler Everywhere RAW export of LinkedIn (Voyager API) traffic into markdown lists of Posts, Reactions, Profiles, Messages, and Groups. Use when a LinkedIn capture into social/linkedin/ is dropped and wants it turned into readable lists.
user_invocable: true
---

# LinkedIn — Fiddler capture parser

 Captures LinkedIn web traffic in Fiddler Everywhere and exports the **RAW**
capture into a dated folder under:

```
[local path]social/linkedin/<YYYY-MM-DD-HHMMSS>/
```

Fiddler saves each captured HTTP **response body** as a file on disk, laid out
as `<dump>/<hostname>/<url-path>[index]`. The signal lives under
`www.linkedin.com/voyager/api/*` — LinkedIn's internal "Voyager" JSON API. Each
file is one JSON response body (no HTTP headers). The bodies are
`$type`-discriminated entity graphs.

This skill turns that raw network exhaust into five readable markdown lists:

- **Posts** — feed updates (`feed.Update`): author, age, commentary text, permalink
- **Reactions** — likes/etc (`social.Reaction`): reactor name, headline, target activity
- **Profiles** — people seen (`identity.profile.Profile`): name, headline, premium, profile link
- **Messages** — DMs (rich messenger graph under `voyagerMessagingGraphQL/`):
  grouped by conversation, showing who each thread was **with**, a permalink to
  the thread, and every captured message (timestamp, sender, text; the user's
  own outbound messages are labelled **Me**)
- **Groups** — groups seen (`groups.Group`): name, member count, visibility, link

## When to invoke

- "Parse the LinkedIn export"
- "Turn the latest LinkedIn capture into lists"
- "What posts/reactions/messages are in social/linkedin?"
- `/linkedin-parse`

## Steps

1. **Run the parser.** It defaults to the newest dated dump under
   `social/linkedin/`.
   ```bash
   cd [local path]
   python3 [local path].claude/skills/linkedin-parse/parse_linkedin.py
   # or a specific dump:
   python3 [local path].claude/skills/linkedin-parse/parse_linkedin.py [local path]social/linkedin/2026-06-03-154246
   ```
   It writes to `social/linkedin/_reports/<dump-name>/`:
   - `posts.md`, `reactions.md`, `profiles.md`, `messages.md`, `groups.md`
   - `README.md` — index with counts
   - `data.json` — structured sidecar for downstream tooling

2. **Read the generated reports** (or just the counts the script prints). Don't
   paste whole files backm. Give a short briefing: counts per
   list, plus 2–4 highlights (notable posts in the feed, who reacted to Kin's
   posts, any inbound message threads, new groups).

## How it works (so you can answer questions about it)

- Walks every JSON body under `www.linkedin.com/voyager/api/` (recursively, so
  it reaches subdirs like `voyagerMessagingGraphQL/`), visiting every dict node.
- **Name resolution:** LinkedIn profile URNs are opaque (`ACoAA...`). For the
  feed, names come from `ActorComponent` (post author) and `EntityLockupViewModel`
  (reaction reactor) blocks, each pairing a display name with a `*profile` URN in
  its image attributes. For messages, names come from the messenger graph's
  `MessagingParticipant` records — `participantType.member` gives first/last name
  and profile URL, `participantType.custom` gives sponsored-InMail names, and
  company participants fall back to captured `Company` names.
- **Messages** are decoded from the rich messenger graph (`_type`-keyed, e.g.
  `com.linkedin.messenger.Conversation` / `.Message`, not the older `$type`
  format). The viewer ("Me") is the first profile in each conversation URN tuple;
  everyone else in the roster becomes the thread's "with". Thread permalinks come
  from each conversation's `conversationUrl`. Output is grouped by conversation,
  sorted most-recent-first, messages chronological within a thread.
- De-dupes by entity URN / activity id / message backend URN so the same item
  appearing across multiple captured responses is listed once.
- It does **not** parse anything outside `voyager/api`. Coverage is whatever
  threads/messages were loaded in the browser while capturing — an unnamed
  "Unknown" thread just means that participant's name was never in the capture.

## Notes / limits

- Coverage depends entirely on what is scrolled past while capturing. A bigger
  list means more was loaded in the browser, not that more exists.
- Profiles often have no name (only the headline) when the profile was returned
  without ever appearing in a feed/reaction lockup. Those still list by headline
  and profile link.
- Re-running is safe and idempotent — it overwrites the report folder for that
  dump.

## Related

- `me-daily` skill summarizes the *same kind* of Fiddler dumps at the
  host/category level (who was talked to). This skill goes the other way:
  decoding the LinkedIn response bodies into actual content lists.

Markdown Files

The reason I like using Claude as an extension in VSCode is that it is easy for Claude to work with entire folders of files, like the Fiddler RAW export, but also it can then easily output multiple markdown files. I had it dump a groups.md, messages.md, posts.md, profiles.md, and reactions.md, as well as a README.md and data.json dump for each time I run a report. Then I can reference the context for a specific research session, day, or other bounded context I wish. It gives me full control over my data, within the bounded context that matters to whatever I am trying to accomplish.

My LinkedIn Data

I’ve done this work to satisfy my needs. Giving me control over my LinkedIn data. But I am sharing it in response to a couple friends who have asked for how to do it. They’ve been struggling to get control of their data, frustrated with having to request their entire archive from LinkedIn, or getting warned for using Chrome extensions and other methodologies. This approach gives you full control over your data locally on a daily or other basis, and what you do with the data is up to you. Claude can easily work across the folders and markdown files in VSCode, but you will need to refine if you don’t use VSCode.

I’ve published a video below to walk through some of it to try and outline the steps. But it would need much more work to refine and turn into a tutorial that anyone can follow. So you will have to accept this unpolished story and video, and if you need more help feel free to reach out. I am happy to help and make more time to refine, but for my purposes it has accomplished what I needed, and I am using it daily to align my LinkedIn reality with my Gmail, Google Calendar, Bluesky, YouTube, and other activities. Storing all my data locally as markdown, which I then sync using GitHub and Amazon S3, and then using Claude to help me make sense of my world in real-time, without having to play the games that LinkedIn, and many other platform providers, make us play.

Your existing API management platform does not do this for you currently out of the box.

I spent the last week looking through every API gateway and API management OpenAPI in my API Evangelist network — Kong, Apigee, Tyk, WSO2, Gravitee, AWS API Gateway, Azure APIM, Google Cloud API Gateway, MuleSoft, Workato, and others — looking for the operations that would compose into an “agent shows up and self-registers” flow. The operations exist. Every Tier 1 gateway can create a developer, create an app, issue a scoped key, attach a rate limit policy, and stream an audit event. The pieces are there. What’s missing is the composition — the single endpoint that takes a signed onboarding request and orchestrates the three-to-five gateway calls needed to turn it into a credential the agent can use. No gateway has shipped that endpoint.

I see this as the job of a Naftiko Capability.

The Flow

What the agent experience needs to look like:

1. Agent fetches /.well-known/api-catalog per RFC 9264. The catalog includes an x-onboarding extension pointing at the consent document, the supported signature scheme, and which scopes auto-issue versus require approval.
2. Agent fetches /skills/onboard-agent.md from the provider’s published agent skills directory. The skill is the operating manual — it tells the agent how to construct the request.
3. Agent computes a SHA-256 hash of the consent document it just read.
4. Agent constructs an HTTP signature over its onboarding request (per Web Bot Auth), includes the consent hash, the skill ID, the requested scopes, and an operator contact, and POSTs to /onboard.
5. The provider’s edge worker verifies the signature, calls the onboarding capability behind it, and returns a scoped credential. Or, for scopes that need human approval, returns a 202 Accepted with a status URL the agent polls.

One round trip for the auto-issuable scopes. A clean async-with-status pattern for the rest. The agent never sees the gateway. The gateway never sees the Web Bot Auth signature. The capability is the seam.

Why It’s a Capability, Not a Gateway Feature

I have been blah blah blahing about Naftiko Capabilities for most of 2026. The shorthand: a Naftiko Capability is a declarative, domain-aligned unit of integration. It composes operations across one or more underlying services, and produces consistent surfaces (REST, MCP, Agent Skills) on top of whatever inconsistent operations sit underneath. You can generate them from OpenAPIs. You can govern them with Spectral rules. You can run them through the Naftiko Framework (Ikanos) on top of whatever existing API or data source sits behind them.

The agent onboarding flow is a textbook capability problem. Read why:

• It composes operations across at least two gateway surfaces. Even on the cleanest gateway (Kong), the flow is POST consumers → POST consumer_groups → POST consumer_groups/{cgId}/consumers → POST consumers/{cid}/key-auth → stream audit event. That’s five operations. On Apigee it’s four operations spread across two API surfaces (Management + Cloud Audit Logs). On AWS it’s three operations spread across three surfaces (API Gateway, IAM, CloudTrail).
• The scope vocabulary is gateway-native and ugly. Kong has ACL plugin tags. Apigee has API Products. WSO2 has throttling policies. Tyk has access_rights arrays. The provider should declare scopes once in human-readable terms (read:public, write:invoices) and have the capability translate to whichever gateway-native primitive applies. That translation is exactly what Naftiko Capabilities are for.
• The policy surface is declarative. Trusted issuers, auto-issuable scopes, approval channels, default rate limits, consent terms, audit destination. All YAML. Editable by the provider without touching the gateway. The capability enforces the policy on every onboarding request.
• The outputs are multi-surface. The same capability publishes a REST endpoint (POST /onboard), an MCP tool (agent.register), and an agent skill (onboard-agent.md). One declaration, three derivative surfaces. That is the Naftiko Capabilities pattern exactly.

The gateway team is unlikely to ship this for you. Kong is not going to write the adapter. Apigee is not going to write a Web Bot Auth verifier in Apigee’s policy language. WSO2 has almost shipped this in the form of dynamic client registration (POST /register), but they didn’t model agent identity and they didn’t ship the consent-hash or scope-translation legs of the flow. None of these vendors will. It is not their business model.

The vendor that ships it is the one that treats the flow as a portable capability that runs in front of any of them.

What the Capability Actually Contains

An agent-onboarding Naftiko Capability declares roughly the following — note this is an illustrative sketch of the shape, simplified for the post. The first real artifact, against Kong Enterprise Admin, is committed at api-evangelist/kong/capabilities/kong-agent-onboarding.yaml and uses the canonical naftiko: 1.0.0-alpha2 schema with consumes + orchestration + exposes sections per the Ikanos specification.

naftiko: 1.0.0-alpha2
info:
  label: Agent Onboarding (gateway-templated)
  description: Verify agent identity, check policy, compose gateway operations,
    return a scoped credential, emit audit. Valid against the canonical
    naftiko 1.0.0-alpha2 schema; the Kong and AWS reference artifacts use
    this exact shape.
  tags: [Agent Onboarding, Web Bot Auth, RFC 9421]
binds:
- namespace: env
  keys:
    GATEWAY_ADMIN_TOKEN: GATEWAY_ADMIN_TOKEN
    AGENT_TRUSTED_ISSUERS: AGENT_TRUSTED_ISSUERS
    AGENT_CONSENT_HASH: AGENT_CONSENT_HASH
capability:
  consumes:
  - type: http
    namespace: gateway-admin
    baseUri: ''
    description: The 3-5 gateway-native operations the orchestration composes.
    resources:
    # See per-gateway artifacts for exact resource paths — Kong uses
    # /{workspace}/consumers + /{workspace}/consumer_groups + key-auth;
    # AWS uses /apikeys + /usageplans + /usageplans/{id}/keys; etc.
    - name: identity
      path: /{gateway-native-identity-path}
      operations:
      - { name: createidentity, method: POST }
    - name: scope-tier
      path: /{gateway-native-scope-path}
      operations:
      - { name: ensurescopetier, method: POST }
    - name: credential
      path: /{gateway-native-credential-path}
      operations:
      - { name: mintcredential, method: POST }
    authentication:
      type: apikey
      key: Authorization
      value: ''
      placement: header
  orchestration:
  - name: onboard-agent
    description: End-to-end agent onboarding — 7 steps from signature to credential.
    inputs:
    - { name: signature, type: object, required: true }
    - { name: signature_agent, type: string, required: true }
    - { name: skill_id, type: string, required: true }
    - { name: requested_scopes, type: array, required: true }
    - { name: consent_hash, type: string, required: true }
    - { name: contact, type: object, required: true }
    steps:
    - id: verify_identity
      type: builtin.web-bot-auth.verify
      with:
        signature: '${input.signature}'
        agent: '${input.signature_agent}'
        trusted_issuers: ''
      on_failure: deny
    - id: verify_consent
      type: builtin.policy.assert
      with:
        assert: '${input.consent_hash} == '
      on_failure: deny
    - id: classify_scopes
      type: builtin.policy.scope-classify
      with:
        requested: '${input.requested_scopes}'
    - id: create_identity
      call: gateway-admin.createidentity
      with:
        body:
          agent_id: '${steps.verify_identity.agent_id}'
    - id: ensure_scope_tier
      type: builtin.upsert
      with:
        name: '${steps.classify_scopes.target}'
    - id: mint_credential
      call: gateway-admin.mintcredential
      with:
        identity_id: '${steps.create_identity.id}'
        scope_tier: '${steps.ensure_scope_tier.id}'
    - id: emit_audit
      type: builtin.audit.emit
      with:
        event: agent.onboarded
        agent_id: '${steps.verify_identity.agent_id}'
        credential_id: '${steps.mint_credential.id}'
    output:
      agent_id: '${steps.verify_identity.agent_id}'
      credential: '${steps.mint_credential.value}'
      scope: '${steps.classify_scopes.target}'
  exposes:
  - type: rest
    namespace: agent-onboarding-rest
    port: 8080
    resources:
    - path: /v1/agents/onboard
      operations:
      - { method: POST, name: onboardagent, call: orchestration.onboard-agent }
  - type: mcp
    namespace: agent-onboarding-mcp
    port: 9090
    transport: http
    tools:
    - { name: agent-register, call: orchestration.onboard-agent }
  - type: agent-skill
    namespace: agent-onboarding-skill
    skill: { name: onboard-agent, file: skills/onboard-agent.md }

The runtime policy levers (require Web Bot Auth signature, require matching consent hash, deny forbidden scopes, defer approval-required scopes to a webhook) are already encoded in the orchestration steps via on_failure: deny — there is no separate governance: capability section to author. Policy enforcement is what the orchestration is.

The lint-time governance — the rules that say “any capability claiming to do agent onboarding MUST include verify_signature, verify_consent, classify_scopes, and emit_audit steps, MUST bind AGENT_TRUSTED_ISSUERS and AGENT_CONSENT_HASH in its env namespace, and MUST expose REST/MCP/agent-skill surfaces on the canonical paths” — lives in a Polychro ruleset, not in the capability YAML. Polychro is Naftiko’s governance layer, separate from the capability spec. The companion ruleset for this pattern is at api-evangelist/posts/polychro/agent-onboarding-rules.yaml — 17 rules extending polychro:ai-safety, applied with polychro lint --tags agent-onboarding.

The three-layer split is the correct architecture per the canonical Naftiko docs: Ikanos is the capability spec (the YAML above), Polychro is the governance layer that lints capability files, and Naftiko Fleet is the operations layer that governs capabilities at scale across teams and compliance boundaries. None of those three is encoded inside the others.

The capability is a single artifact. It declares what the agent will send, what trust is required, which gateway operations get composed in which order, what the policy levers are, and which surfaces are produced. The Naftiko Framework runs it. The provider edits policy.yaml and re-deploys without ever touching the capability or the gateway. Ten reference artifacts are now committed across the API Evangelist GitHub organization, all valid naftiko: 1.0.0-alpha2 against the canonical schema and all exposing the same three downstream surfaces — REST POST /v1/agents/onboard, MCP agent-register tool, and an agent skill at /skills/onboard-agent.md — so an agent that knows how to call the onboarding endpoint doesn’t care which capability sits behind it:

That’s ten gateway adapter shapes, all expressed as Naftiko Capabilities, all parsing with stock yaml.safe_load, all following the same consumes + orchestration + exposes structure documented in the canonical Ikanos capability spec. The differences across the ten reflect the gateway data models and trust affordances — not the agent-facing contract. The orchestrations range from Tyk’s five-step minimum (one atomic gateway call) to Kong and Azure APIM’s eight-step composition; the shape of the contract above each of them is identical. The companion Polychro ruleset lints every one of the ten artifacts for cross-capability consistency — same verify_signature / verify_consent / classify_scopes / emit_audit step contract, same REST/MCP/agent-skill exposed surfaces, same required env bindings.

The gateway-specific operation paths above are not invented — they are pulled directly from the OpenAPIs published across the API Evangelist GitHub organization at api-evangelist/kong/openapi, api-evangelist/apigee/openapi, api-evangelist/wso2/openapi, api-evangelist/tyk/openapi, and the rest. I evaluated all of them this week and produced an inventory matrix scoring 75 gateway providers by how cleanly they can drive each leg of the flow.

What the Eval Surfaced

Four pieces of work behind this post — an adapter specification (the formal contract any per-gateway adapter must implement: listAPIs, getSpec, issueCredential, streamAuditEvents, listMCPServers), a Kong vs. Apigee deep dive (Kong’s adapter is ~4.5 days, Apigee’s is ~6.5 days plus a Cloud Audit Logs side-channel), a gateway inventory across 75 providers (Eight Tier-1 turnkey targets, thirty-three Tier-2 needing audit side-channels, thirty-four Tier-3 with thin OpenAPI surfaces), and the automated onboarding flow specification itself.

Three findings worth pulling out of that work:

Three gateways already publish first-class MCP operations. WSO2 has seventy MCP-related operations in their Publisher and Devportal APIs, including createMCPServerFromOpenAPI and createMCPServerFromAPI. Workato has sixteen MCP-server-management operations including assigning tools to a server and renewing server tokens. Kong has thirteen MCP control-plane operations. Apigee, Tyk, Gravitee, AWS, and Google Cloud all have zero. The agent onboarding capability for those first three gateways doesn’t just enable MCP — it discovers and orchestrates MCP servers the gateway is already operating. That’s a meaningful value-add that no one is talking about.

Audit observability is where the field splits. The Web Bot Auth signature that proves which agent registered needs to land somewhere the provider can later prove who-onboarded-whom. Kong, WSO2, and Gravitee ship native audit operations in their OpenAPI. Apigee, AWS, Google, and Azure push audit to their unified cloud audit log services — out of band from the gateway. The capability has to know how to talk to both shapes.

The standardized package is two layers. A gateway-independent core (linkset emitter, robots.txt template, JSON-LD context, agent skill templates, the edge worker that injects RFC 8288 Link headers) sits on top of a per-gateway adapter (the operation-composition layer). The first half is approximately the May 16 agent-readiness work generalized. The second half is new per gateway.

Why I’m Writing This Up Without Shipping It Yet

I don’t have a live gateway tenant to run any of this against this spectrum. All ten capability artifacts are complete, schema-valid Naftiko Capability declarations, but none of them has yet been executed against a real customer environment. The full series of artifacts is design-validated — every YAML parses, every consumes block maps to operations the gateway actually publishes, every orchestration step references either a builtin or a consumed operation defined elsewhere in the same file — but the artifacts have not yet been deployed against any customer’s gateway tenant. I’m publishing the design before the implementation for three reasons.

One: I am actively looking for design partners. If you run an API program — at any scale — and the “we cannot onboard agents fast enough” problem is real for you, I would like to talk. Every major commercial API gateway in the field now has a committed reference capability; running any of them against a real customer tenant is one engagement away. The customer that goes first on any given gateway shapes the policy surface, the trust model, and the credential lifecycle to fit their needs while the standardized package is still being defined.

Two: The design is more useful in public than in private. Every API gateway vendor I have talked to in the last two months is wrestling with some version of this question, and every API provider I have talked to is wrestling with the other side of it. Publishing the operation-by-operation map of how each major gateway’s existing API surface composes into this flow is a contribution to a conversation that needed somewhere to land. The conversation should not have to start over every time a provider gets asked “can your agent self-register against us.”

Three: The work is the thing. I have been doing API Evangelist for fifteen years, and the pattern that has been most consistently true is that the design specs I publish early get implemented by people who needed exactly that design spec — sometimes by my customers, often by other vendors, occasionally as the eventual canonical version of the thing. The agent onboarding capability is a pattern that needs to exist. Whether I ship the reference implementation or whether someone else does, the capability shape above is what should ship. Writing it down clearly and pointing at the gateway operations that compose into it is the contribution worth making first.

What’s Updated

I have refreshed both my API Evangelist services page and the APIs.io services page to lead with the automated onboarding angle on the agentic-preparation service. The doorway pattern is still there — .well-known/api-catalog, .well-known/mcp, agent skills, secure credential issuance — but it now leads with the automated framing because that is what the work this week made clear is the actual differentiator. A doorway that requires a human at the gate is a portal. A doorway that recognizes a signed agent and provisions it in one round trip is a different thing.

If you are running an API program and your agents-need-credentials story is currently “they file a Jira ticket like everyone else,” let’s talk. Ten reference capabilities are committed across the API Evangelist GitHub organization, one per major gateway. The one that matches whichever gateway you operate is one engagement away from being executed against your tenant.

This week I ran an experiment to make that claim concrete. For each of the 989 Fortune 1000 companies that I already have a repo for in the API Evangelist GitHub Organization, I pulled three things and stored them as markdown right next to the existing apis.yml:

• The top five Google results for "<company> artificial intelligence".
• The top five results for "<company>" press release artificial intelligence.
• The top five results for "<company>" blog artificial intelligence.

Every artifact lands as a markdown file with YAML frontmatter (title, url, date, query, position, source). Then a second pass walks each company directory, counts mentions across a 35-term lexicon — artificial intelligence, AI, machine learning, LLM, generative ai, foundation model, copilot, agentic, RAG, GPT-x, OpenAI, Anthropic, ChatGPT, and a couple dozen more — and writes a per-company AI-INVESTMENT.md report. A final pass aggregates everything into a single rollup.

The numbers

• 989 Fortune 1000 companies have a repo and a full report.
• 44,025 AI-term mentions across all the pulled markdown.
• 19,609 of those are the exact string artificial intelligence.
• 44.5 AI-term mentions per company on average.
• 0 companies with zero AI signal across all pulled markdown.

That last number is the headline. Even the Fortune 1000 companies you wouldn’t expect — Universal (the tobacco company at rank #854), Pep Boys at #850, Pinnacle Entertainment at #976 — produced at least one Google result mentioning AI somewhere in the snippet. The question of “is your industry talking about AI yet” is closed. Yes. All talking about it. The question is, what are they doing about it, and that reflects the work I am doing with Naftiko Signals.

Three lenses, three different leaderboards

The first lens is raw mention count. It looks like this:

If you stop reading after this table you will draw the wrong conclusions. American Express and Hanover Insurance lead because they happened not to expose an RSS feed on their corporate homepage. That means their data is entirely the 15 search engine snippets I asked for — and those snippets are 100% AI-themed by query design. Microsoft, sitting at #31 in the same ranking with 90 mentions, did expose a feed. So Microsoft also has twenty broad blog posts in the sample, most of them not about AI, which drags the raw mention count down.

This is sample-size bias, not signal. To correct for it I added a second lens: AI / item, the average number of AI hits per pulled markdown file. Companies with fewer than ten items don’t qualify. The picture flips:

Hanover and Amex stay on top because their broader RSS-discovered items also happened to mention AI — twenty of twenty-five blog posts, twenty-four of twenty-eight, respectively. That is genuine density, not selection.

The third lens is the one I find most useful: how many of the items in a company’s press/ directory actually mention AI. Press releases are the most authoritative channel — those are the things the company chose to put its own logo on. This leaderboard is different again:

Notice how Alphabet barely registers in the raw count (#29) but jumps to #2 here because their press feed surfaced thirteen distinct AI announcements. Union Pacific shows up at #10 — a railroad, in a list otherwise full of software and finance. That is worth a look.

Industry density

Aggregating by industry and dividing by company count gives a cleaner read on which sectors are uniformly engaged with AI versus which have a few loud companies and a long quiet tail:

Software and networking lead, which surprises no one. Banks and insurance at #3 and #6 are the interesting story — financial services has gone from “AI is interesting” to “AI is part of the press cadence” faster than I would have predicted three years ago.

The methodology

Some caveats, because I am not going to pretend this is a clean academic measurement:

• The lexicon is permissive. \bAI\b matches any standalone “AI” — and most of the time that is what we want, but in a press release that lists a product code like “AI-204” it will overcount. I accept this tradeoff. The point is to find which companies are talking about AI a lot, not to write a definition of AI.
• RSS coverage is patchy. Of 989 companies, only 197 exposed a discoverable RSS feed for blogs or press from their corporate homepage. The rest have no machine-readable channel for their own announcements. The remaining 792 companies are visible to this analysis only through search engines view. That is a real story about how few Fortune 1000 companies bother to publish a feed in 2026, separate from this analysis.

What I’m taking away

Three things.

The first is that “is your industry doing AI” is the wrong question now. The signal floor is non-zero across every industry in the Fortune 1000, including the ones I expected to come up empty. Mining. Tobacco. Specialty retail. All of them have public AI mentions findable in three search engine queries.

The second is that the interesting differentiation is not raw volume but channel and density. Alphabet putting thirteen AI announcements through its press feed is a different signal than American Express having a lot of AI articles written about it. Both matter. They are not the same thing.

The third is that this entire pipeline took an afternoon to build, ran in under an hour of API time, and produced 989 company reports plus a ranked rollup as markdown that I can grep, version, and link to. That is the version of “AI investment analysis” I want to do: build it once, run it everywhere, store the receipts as plain markdown next to the rest of the company’s API and capability data, and let the index be the artifact.

Honestly I don’t know what any of this means. It all feels like noise. I will be doing the diff with the signals I’ve been gathering as part of my Naftiko work. Search engines, blogs, press releases for the Fortune 1000 spin one narrative, the job postings and GitHub repos (if they have) tell another. I think the jobs are the leading indicator for whether it is all talk or if there is any actual investment. Also, with the job postings I don’t think it is just about hiring for AI terms, and is about hiring for data, pipelines, APIs, and all the things that will determine if you are successful.

I have been writing about this pattern for the better part of two years. I added well-known-catalog as a forward-looking dimension in the agent-readiness model I shipped this week. And I noticed yesterday, while writing up Merge.dev’s pipeline refresh, that Merge had quietly added one — ten entries, one per Unified API category, with the OpenAPI YAML on each typed link. That made me wonder how many other providers I’d missed.

So I ran a probe. Seventy-four providers — every company in the recent round of API Evangelist pipeline refreshes (the embedded iPaaS players, the identity providers, the cloud gateways, the docs platforms, the SDK generators, the agent infrastructure companies, the observability vendors) plus the obvious large surfaces that should have one if anyone does (Stripe, Twilio, GitHub, Salesforce, Microsoft Graph, Google, Postman, Plaid, Slack, Shopify, every API gateway). Six URL candidates per provider — bare domain, docs., developer., developers., api., platform.. Five hundred and eighteen HTTPS requests, fired in parallel.

The answer is four

Four providers serve a real RFC 9727 LinkSet at /.well-known/api-catalog:

That is the entire field as of today. Four out of seventy-four.

Two providers returned a clean 404. Sixty-eight returned 200 OK — but the body was HTML. They were single-page-app catch-all routes serving the homepage from the well-known path. An agent following the standard would get a 200, try to parse a LinkSet out of the body, fail, and have no useful recourse. That is worse than a 404. A 404 tells the agent the resource doesn’t exist; an HTML 200 at a well-known path lies.

The four are not who I expected

I expected Stripe to have one. They don’t.

I expected Twilio to have one. They don’t.

I expected at least one of the big docs platforms — ReadMe, Mintlify, Bump.sh, Redocly, Stoplight — to have one for their own site, given that publishing developer-facing infrastructure is the entire business. None of them do.

I expected every API gateway in the field to have one as a credibility signal. Of the seven I probed — Kong, Tyk, Apigee, Apache APISIX, Gravitee, KrakenD, WSO2 — none do. Only Zuplo. Cloudflare does it on the docs site, which is the closest the hyperscaler gateways get.

I expected, frankly, that any of the agent infrastructure companies — Composio, Toolhouse, Smithery, Letta, Arcade, Jentic, Naftiko — would have one as their literal job description. None do.

What I got instead was a CDN/edge company, a small startup most people have never heard of, a unified-API company, and a developer-first gateway company. The shape of the field that has actually implemented this is not the shape of the field that talks about agent readiness.

What good looks like

The Memesio catalog is the one I’d point any provider at as a template. It is two lines:

{
  "linkset": [
    { "anchor": "https://memesio.com/api",
      "service-desc": [{"href": "https://memesio.com/api/openapi", "type": "application/json"}]
    },
    { "anchor": "https://memesio.com/api/mcp",
      "service-desc": [{"href": "https://memesio.com/api/mcp", "type": "application/json"}]
    }
  ]
}

That is the entire payload an agent needs to discover both the REST API and the MCP server. It costs you a single static file behind a CDN. It costs you nothing to maintain. It is the smallest, cheapest, most boring agent-readiness commitment you can make as a provider — and it makes the difference between an agent that finds your API in one round-trip and an agent that has to crawl your blog.

The Merge catalog is the second template — the multi-product version. If you ship one product, you can fit the whole story in one entry like Cloudflare or Zuplo. If you ship a family of APIs like Merge does (or like Stripe does, or Twilio, or Salesforce), one entry per product line is the move. You do not have to pick which to advertise. You advertise all of them.

What the gap means

The gap is not a standards-maturity gap. RFC 9727 has been published for over a year. It builds on RFC 9264 LinkSet, which itself was published in 2022. The IETF httpapi WG has been clear about the design.

The gap is a prioritisation gap. Every provider I named above ships agent-themed product launches, AI gateway integrations, MCP servers, “Auth for AI” press releases. The smallest possible agent-readiness primitive — one well-known path that returns a tiny JSON document pointing at the OpenAPI you already publish — is the thing they have skipped. It’s the API-publishing equivalent of selling a beautiful house without putting up a number on the mailbox.

I’m going to start using this as one of the first signals I check when I write up a provider. If you ship a /.well-known/api-catalog you’re telling me you’ve thought about agents finding your API by themselves. If you don’t, you’re telling me you’ve thought about agents using your API only after a human has already onboarded them. Those are two different products.

If you work at a provider with a public API, your TODO is one PR. Add a linkset JSON file. Serve it with Content-Type: application/linkset+json; profile="https://www.rfc-editor.org/info/rfc9727". Point it at the OpenAPI you already publish — and at your MCP server if you have one. That’s the whole task. You will join Cloudflare, Memesio, Merge.dev, and Zuplo on the very short list of providers an agent can actually find without me writing a custom crawler.

The signal records for all four observed catalogs are committed in the api-evangelist/agent-readiness topic repo, scored as exemplary against the well-known-catalog dimension. I’ll re-run the probe next quarter. I’d like the table to be longer.