<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>API Evangelist</title>
  <updated>2026-06-14T00:00:00Z</updated>
  <link rel="self" href="https://apievangelist.com/atom.xml"/>
  <author><name>Kin Lane</name></author>
  <id>https://apievangelist.com/atom.xml</id>
	<entry>
    <title>The Architecture Behind 10,000 API Providers</title>
    <link href="http://apievangelist.com/2026/06/14/the-architecture-behind-10000-api-providers/"/>
    <updated>2026-06-14T00:00:00Z</updated>
    <content><![CDATA[When I started API Evangelist in September 2010, I was writing stories from a one-bedroom apartment in Eugene, Oregon, trying to make sense of what Twitter, Twilio, and Stripe were doing to software development. I had no idea it would eventually turn into a catalog of 10,000 API providers indexed across a searchable network. But here we are. 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...]]></content>
    <id>http://apievangelist.com/2026/06/14/the-architecture-behind-10000-api-providers/</id>
  </entry><entry>
    <title>Your Diverse API Toolbox</title>
    <link href="http://apievangelist.com/2026/06/12/your-diverse-api-toolbox/"/>
    <updated>2026-06-12T00:00:00Z</updated>
    <content><![CDATA[I have been writing about this since March 2017, kept expanding it through 2018 with a diagram that I brought to talks and workshops, and reinforced it again in 2020. Coming back from APIDays Amsterdam, the same message needs saying again — now with MCP and Agent Skills freshly added to the shelf. 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”...]]></content>
    <id>http://apievangelist.com/2026/06/12/your-diverse-api-toolbox/</id>
  </entry><entry>
    <title>History of API Evangelist</title>
    <link href="http://apievangelist.com/2026/06/12/history-of-api-evangelist/"/>
    <updated>2026-06-12T00:00:00Z</updated>
    <content><![CDATA[One story I’ve told many times, but couldn’t find in my own historical archives of API Evangelist, is the origin story of API Evangelist itself. I am learning that the stories I’ve told over the years on API Evangelist provide a lot of context for my use of AI in my research, and filling in the gaps where AI stumbles is proving to be important. 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...]]></content>
    <id>http://apievangelist.com/2026/06/12/history-of-api-evangelist/</id>
  </entry><entry>
    <title>API Value Exchange</title>
    <link href="http://apievangelist.com/2026/06/12/api-value-exchange/"/>
    <updated>2026-06-12T00:00:00Z</updated>
    <content><![CDATA[I have been writing about API monetization since 2011. Not consistently, but in recurring waves — whenever the business reality of APIs forces itself back to the surface. Early on I was fascinated by the mechanics: resource-based versus experience-based pricing, the cost-to-value accounting framework I tried to formalize, the uncomfortable question of whether open government data could ever generate revenue without betraying its public mission. I spent a lot of time in that era trying to help government agencies — the Forest Service, the National Park Service, the Bureau of Land Management — understand that the value flowing through their APIs was real and worth naming, even if calling it “monetization” was politically untenable. 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...]]></content>
    <id>http://apievangelist.com/2026/06/12/api-value-exchange/</id>
  </entry><entry>
    <title>Industrial Manufacturing APIs and the AI Integration Gap</title>
    <link href="http://apievangelist.com/blog/2026/06/05/industrial-manufacturing-apis-and-the-ai-integration-gap/"/>
    <updated>2026-06-05T00:00:00Z</updated>
    <content><![CDATA[I spent the last week cataloging the industrial manufacturing API landscape, doing a proper inventory of what is out there, what APIs providers expose, what vocabulary they use to describe themselves, and what machine-readable artifacts are available for integration. I pulled 421 providers across the manufacturing, industrial automation, IIoT, robotics, SCADA, MES, CMMS, PLM, and supply chain segments. Then I ran an enrichment pipeline across 56 of the most specifically API-facing providers to find out how many had publicly discoverable OpenAPI specifications. 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: Tag Count Manufacturing 143 Industrial 58 Supply Chain 44 IoT 36 Aerospace 36 Automotive 34 Construction 40 Industrial Automation 12 Industrial IoT 16 SCADA clustered under Industrial CMMS handful MES handful 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...]]></content>
    <id>http://apievangelist.com/blog/2026/06/05/industrial-manufacturing-apis-and-the-ai-integration-gap/</id>
  </entry><entry>
    <title>The APIs of the World's Top Universities — 634 of Them, and Most Are Library Plumbing</title>
    <link href="http://apievangelist.com/blog/2026/06/04/the-apis-of-the-worlds-top-universities/"/>
    <updated>2026-06-04T00:00:00Z</updated>
    <content><![CDATA[I pulled the API surface for 219 of the world’s top-ranked universities — the QS World University Rankings 2025 set that I built into the API Evangelist network — and went looking for the interesting stuff. Which schools publish the most? Which countries show up? And what kind of APIs do universities actually have? 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: Region Universities Europe 88 North America 51 Asia 40 Oceania 21 Middle East 7 South America 2 Africa 1 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: APIs University Country 8 UCL (University College London) United Kingdom 8 University of California, Santa Barbara United States 6 ETH Zurich Switzerland 6 University of Pennsylvania...]]></content>
    <id>http://apievangelist.com/blog/2026/06/04/the-apis-of-the-worlds-top-universities/</id>
  </entry><entry>
    <title>Obtaining the Control Over Your LinkedIn Data That You Desire</title>
    <link href="http://apievangelist.com/blog/2026/06/03/obtaining-the-control-over-your-linkedin-data-that-you-desire/"/>
    <updated>2026-06-03T00:00:00Z</updated>
    <content><![CDATA[I have ranted several times about how tightly LinkedIn controls our personal user data. They refuse to give you access to your personal profile data via the LinkedIn API. You can access your company pages via the API, but everything is centered around your desire to run LinkedIn ads. I simply want access to MY data via the platform. I am not asking for much. I have tried every SaaS and Chrome extension out there that promises to do this for you, and have been unable to obtain access to my data daily in the manner that I wish. It is unacceptable. 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,...]]></content>
    <id>http://apievangelist.com/blog/2026/06/03/obtaining-the-control-over-your-linkedin-data-that-you-desire/</id>
  </entry><entry>
    <title>Automated Agent Onboarding Is a Naftiko Capability, Not a Gateway Feature</title>
    <link href="http://apievangelist.com/blog/2026/05/27/automated-agent-onboarding-as-a-naftiko-capability/"/>
    <updated>2026-05-27T00:00:00Z</updated>
    <content><![CDATA[An agent shows up at your API. Not a developer. An agent — Claude doing research for someone, an OpenAI Operator running a task for a user, a first-party agent your own company built. It carries a verifiable identity (a signed request, per Web Bot Auth over RFC 9421), a published purpose, and a list of scopes it would like. It would like a credential. It would like to start calling APIs. It would like to do this in one round trip, without waiting two business days for a Slack message from a developer relations person who is also juggling four other things. 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: 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. 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. Agent computes a SHA-256 hash of the consent document it just read. 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. 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...]]></content>
    <id>http://apievangelist.com/blog/2026/05/27/automated-agent-onboarding-as-a-naftiko-capability/</id>
  </entry><entry>
    <title>Where Is the Fortune 1000 at When It Coms to AI — Here Are the Receipts for All 989 of Them</title>
    <link href="http://apievangelist.com/blog/2026/05/25/the-fortune-1000-is-saturated-with-ai/"/>
    <updated>2026-05-25T00:00:00Z</updated>
    <content><![CDATA[I now have the majority of Fortune 1000 profiled as part of API Evangelist, so I want to continue understanding where they are with AI. Similar to what I am doing with Naftiko Signals, I want to understand the AI language being used by the Fortun 100. 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 &quot;&amp;lt;company&amp;gt; artificial intelligence&quot;. The top five results for &quot;&amp;lt;company&amp;gt;&quot; press release artificial intelligence. The top five results for &quot;&amp;lt;company&amp;gt;&quot; 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: Rank Company F1000 AI total artificial intelligence 1 American Express #88 327 20 2 Hanover Insurance Group #511 321 34 3 Teradata #809 217 20 4 Juniper Networks #557 166 16 5 Apache #218 161 16 6 Autodesk #862 119 21 7 Cisco Systems #60 115 31 8 Netflix #474 114 18 9 Leidos Holdings #506 113 32 10 Citrix Systems #725 109 18 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...]]></content>
    <id>http://apievangelist.com/blog/2026/05/25/the-fortune-1000-is-saturated-with-ai/</id>
  </entry><entry>
    <title>Only Four API Providers Publish a Real .well-known/api-catalog Right Now</title>
    <link href="http://apievangelist.com/blog/2026/05/22/four-providers-publishing-well-known-api-catalog/"/>
    <updated>2026-05-22T00:00:00Z</updated>
    <content><![CDATA[RFC 9727 has been a published IETF standard for over a year. It defines /.well-known/api-catalog as the machine entrypoint for discovering an organization’s APIs — a small, boring, eminently useful primitive. An agent (or a developer, or a tool) does a GET against that path, gets back an application/linkset+json document, and finds the URLs of every OpenAPI, AsyncAPI, or other spec the provider publishes. No HTML crawl. No “the docs are over here, the spec is over there”. One known place, one machine-readable answer. 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: Provider Endpoint Entries Notable Cloudflare developers.cloudflare.com/.well-known/api-catalog 1 Returns application/linkset+json; profile=&quot;https://www.rfc-editor.org/info/rfc9727&quot;. Points at the bundled openapi.json. Three different host prefixes all resolve to the same content. Memesio memesio.com/.well-known/api-catalog 2 The only catalog I observed that publishes both the REST API and the MCP server endpoint as separate linkset entries. The template the other three should copy. Merge.dev docs.merge.dev/.well-known/api-catalog 10 The deepest catalog — one entry per Unified API category (HRIS, ATS, Accounting, CRM, Ticketing, File Storage, plus the newer ones). Each entry points at a category-specific OpenAPI YAML. The model for how a multi-product provider should structure their catalog. Zuplo zuplo.com/.well-known/api-catalog 1 The only catalog whose typed link explicitly declares the OpenAPI version (application/vnd.oai.openapi+json;version=3.1). A gateway company practicing what they preach. 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 —...]]></content>
    <id>http://apievangelist.com/blog/2026/05/22/four-providers-publishing-well-known-api-catalog/</id>
  </entry><entry>
    <title>Stripe Through the Lens of API Evangelist</title>
    <link href="http://apievangelist.com/blog/2026/05/21/stripe-through-the-lens-of-api-evangelist/"/>
    <updated>2026-05-21T00:00:00Z</updated>
    <content><![CDATA[I have been reviewing API providers for the better part of fifteen years, and Stripe has been on every short list of provider operations I have pointed at as the bar. I have not actually sat down and walked their developer area end-to-end in a while — homepage to docs to GitHub to pricing — and I wanted to do that fresh, the way a developer arriving at stripe.com for the first time in 2026 would. This is what I found. Not a profile of what I have collected about Stripe — a review of what Stripe actually publishes. The Pitch The homepage lede sets the frame for everything that follows: “Financial infrastructure to grow your revenue. Accept payments, offer financial services, and implement custom revenue models—from your first transaction to your billionth.” The top nav is the cleanest API-company nav I see in the field — six items, the developers entry sits as a first-class peer of Products, Solutions, and Pricing. Most providers bury developers two levels deep. Stripe doesn’t. The scale numbers they put on the page are not shy: $1.9T in payments volume processed in 2025 500M+ API requests per day, 10K+ requests per second, 150K+ transactions per minute 200M+ active subscriptions on Stripe Billing 99.999% historical uptime — they cite 99.9999% during Black Friday/Cyber Monday 2025 processing over $40B 135+ currencies and payment methods 50% of the Fortune 100 and 78% of the Forbes AI 50 on the platform You can disagree with any single number but the pattern is unmistakable: Stripe is comfortable putting operational metrics on the homepage that most providers wouldn’t dare quote, because they are confident the metrics hold up. The Docs docs.stripe.com opens with the most minimal headline I have seen on a major provider’s docs landing page: “Documentation — Explore our guides and examples to integrate Stripe.” That’s it. No marketing chest-thumping. The body is then organized around three lanes — Getting Started Use Cases (Accept payments online, Sell subscriptions, In-person payments, Usage-based pricing, Customer Portal), Developer Setup &amp;amp; Resources (Set up your development environment, Build on Stripe with AI, Integration quickstarts), and Browse by Product (the full taxonomy — Payments, Revenue, Money Management, Prebuilt Components). What is missing from the landing page, and worth naming: a one-click changelog, a one-click status page, a one-click SDK list, a one-click support link. Those things exist on Stripe — but they live in nav and footer chrome, not on the docs index itself. A first-time arrival has to know to look for them. Stripe’s information density is high, but discovery for the things that aren’t a use case is a layer down. The “Build on Stripe with AI” entry is new since I last walked through here. It signals that Stripe sees the agent as a developer archetype now, not a future one. The API Reference docs.stripe.com/api is still the API reference everyone else gets compared to. The opening framing is exactly what you would hope a payment API would lead with:...]]></content>
    <id>http://apievangelist.com/blog/2026/05/21/stripe-through-the-lens-of-api-evangelist/</id>
  </entry><entry>
    <title>API Evangelist Scores 83% Agent-Ready — And the Last 17% Doesn't Apply</title>
    <link href="http://apievangelist.com/blog/2026/05/20/api-evangelist-scores-83-percent-agent-ready/"/>
    <updated>2026-05-20T00:00:00Z</updated>
    <content><![CDATA[Cloudflare put out a new tool this week called isitagentready.com. You hand it a URL and it scans for the emerging conventions an agent would look for — robots.txt shape, Content Signals, sitemap, RFC 8288 Link headers, markdown content negotiation, RFC 9727 API catalogs, MCP server cards, Agent Skills indexes, OAuth discovery, agentic commerce protocols. It gives you a number out of 100 and a level. I ran it against apievangelist.com. The result: 83. Level 5. Agent-Native. That’s the second-highest tier the scanner gives out. It’s not nothing — but the more interesting story is what scored and what didn’t. The Three Categories That Scored 100% Discoverability — 3/3. The scanner pulled my robots.txt, validated the structure, extracted the sitemap directive, fetched sitemap.xml, parsed the homepage Link header, and pulled five RFC 8288 link relations — including the api-catalog and alternate; type=&quot;text/markdown&quot; rels that matter for agents. I wrote about this last week — every HTML response across the network now ships a self-describing Link header through the Cloudflare Worker. The scanner saw it. Content — 1/1. Send Accept: text/markdown to my homepage and you get text/markdown; charset=utf-8 back. That’s the Worker doing markdown content negotiation in front of GitHub Pages, which on its own only knows how to serve HTML. This is the single most visible thing the agent-readability work bought me — and the scanner caught it on a 143ms request. Bot Access Control — 2/2. The robots.txt has explicit Allow: / entries for thirteen named AI bots (GPTBot, ChatGPT-User, ClaudeBot, Claude-Web, anthropic-ai, Google-Extended, CCBot, ByteSpider, PerplexityBot, Cohere-AI, Applebot-Extended, Meta-ExternalAgent, FacebookBot, Diffbot) plus a Content-Signal: ai-train=yes, search=yes, ai-input=yes directive declaring consent in the format the Cloudflare Content Signals draft and IETF AIPREF working group are converging on. The point of those last two: my position has always been yes, train on this, yes, ground on this, yes, search this. I am writing for the web, the agents are the web’s new readers. The scanner verified that the consent is published in the right place, in the right shape. API, Auth, MCP &amp;amp; Skill Discovery — 4/6 This is where the score got dinged, and where it gets more interesting. The four passes: API Catalog at /.well-known/api-catalog — RFC 9727 linkset, application/linkset+json content-type, two anchored entries (the contracts API and the agent skills surface). The scanner validated the structure and the type. MCP Server Card at /.well-known/mcp/server-card.json — and at /.well-known/mcp/server-cards.json and at /.well-known/mcp.json. I publish it at all three because the convention hasn’t stabilized; agents pulling from any of those paths get the same SEP-format card. Agent Skills index at /.well-known/agent-skills/index.json — three skills published in the v0.2.0 format with a $schema field. WebMCP — the scanner navigated to the homepage, ran the JavaScript, and found 4 tools registered against navigator.modelContext via the imperative WebMCP API. I have not blogged about that yet. It’s there, and the scanner saw it. The two misses are both OAuth checks: OAuth / OIDC discovery — /.well-known/openid-configuration and /.well-known/oauth-authorization-server both return 404....]]></content>
    <id>http://apievangelist.com/blog/2026/05/20/api-evangelist-scores-83-percent-agent-ready/</id>
  </entry><entry>
    <title>Signals, Stories, and Search</title>
    <link href="http://apievangelist.com/blog/2026/05/19/how-i-built-naftiko-signals-on-top-of-the-api-evangelist-network/"/>
    <updated>2026-05-19T00:00:00Z</updated>
    <content><![CDATA[When we started Naftiko, we needed to understand the market we were entering. That meant getting clear on the market forces and the ideal customer profile, the segments and use cases, and translating the conversations I have been having into personas and problem statements. We also wanted to be honest about the non-functional market requirements, what success metrics would actually look like, and the assumptions I was making along the way. With the ICP established, I set out to find some design partner leads. I started with Bloomberg, because it was the landscape I knew best. I pulled their job postings, press releases, and GitHub repositories, and evaluated the technological areas, services, tools, and standards Bloomberg is investing in. From there I expanded to 292 companies across 49 industries — which gave me an aggregate view of the top areas of investment, the top services, the top tools, and the top standards those companies are betting on. From the job postings, press releases, and GitHub repos I developed a vocabulary of 44 signal groups to identify the meaningful signals of areas, services, tools, and standards being invested in within each company and industry. I applied that scoring to every company, scoring across all 44 areas of potential investment when it comes to integrating artificial intelligence into the enterprise. To help qualify the impact AI is having, I evaluated 26 individual waves that have come as part of the AI market shift, and considered the impact each group of waves is having, as well as the relationship between each wave and each company’s areas of investment, services, standards, and tooling applied to help integrate AI — and other applications — into business operations. Each company has its own landing page with a supporting API and MCP — like EY — and so does the sector they operate within, like professional services. I do not actively publish all of the links to the nearly 300 companies, but I am happy to provide access on request — just email me at kinlane@naftiko.io. My goal is to use them to generate leads, drive conversations, and find other interesting approaches with the right partners. The data is available in aggregate across companies, but also per individual company and per individual industry, surfaced as HTML, Markdown, API, and MCP. I am looking for market data partners to help me further shape the data, the process, and the overall Naftiko Signals product. But wait, there is more. All of the companies in Naftiko Signals — and the services they are investing in — originate from individual repos in the API Evangelist GitHub organization, where I regularly crawl for new APIs and gather machine-readable artifacts including, but not limited to, OpenAPI, AsyncAPI, JSON Schema, Plans, Pricing, Rate Limits, and Naftiko Capabilities. The API Evangelist crawler then feeds the APIs.io search engine, which I am indexing with 14,957 tags and aligning around Naftiko Capabilities. This is the endgame of my API Evangelist work that started in 2010, my APIs.io...]]></content>
    <id>http://apievangelist.com/blog/2026/05/19/how-i-built-naftiko-signals-on-top-of-the-api-evangelist-network/</id>
  </entry><entry>
    <title>Who In The API Evangelist Network Has an MCP Server</title>
    <link href="http://apievangelist.com/blog/2026/05/19/every-api-provider-in-my-network-that-ships-an-mcp-server-grouped-by-tag/"/>
    <updated>2026-05-19T00:00:00Z</updated>
    <content><![CDATA[I just did a fresh pass over every API provider in my network — 6201 repos in the API Evangelist Network — looking for explicit evidence that each provider ships an MCP (Model Context Protocol) server. The bar I used: either an official repo in the company’s own GitHub organization with mcp in the name (attributed back to the specific product, not a sister product), or a first-party blog announcement on the company’s own domain whose title both names the company and uses an announcement verb (introducing, announcing, now generally available, etc.). No third-party tutorials, no “how-to-build-with-MCP” posts, no sister-product attribution. That filter surfaced 199 providers with an MCP server. Below they are grouped by the first tag each provider declares for itself in its apis.yml. 162 sit in tag groups of three or more; the remaining 37 are collected at the bottom under “Other”. The links go directly to the MCP repo or announcement post and to my catalog, so you can verify each one against the source. Open Source (33) Ansible (catalog) — Ansible is an open-source IT automation platform developed by Red Hat that provides agentless configuration management, application deployment, cloud provisioning, and orchestration. Using YAML-based playbooks and an… Apicurio (catalog) — Apicurio is an open source API and schema tooling platform maintained by Red Hat under the Apache 2.0 license. It includes Apicurio Registry (a high-performance schema and API design registry), Apicurio Studio (a visu… Apollo Federation (catalog) — Apollo Federation is an architecture and platform for building a unified supergraph that composes multiple GraphQL APIs (subgraphs) into a single distributed GraphQL endpoint, enabling teams to work independently on d… Appium (catalog) — Appium is an open-source test automation framework governed by the OpenJS Foundation, designed to facilitate UI automation of many app platforms including mobile (iOS, Android), browser (Chrome, Firefox, Safari), desk… Appwrite (catalog) — Appwrite is an open-source backend server for building web and mobile applications. It provides a wide range of features including user authentication, file storage, database management, cloud functions, and messaging… Casdoor (catalog) — Casdoor is an open-source, AI-first identity and access management (IAM) and MCP gateway authentication server with a web UI. Built in Go (Beego) with a React frontend, Casdoor supports OAuth 2.0, OIDC, SAML 2.0, CAS,… Encore (catalog) — Encore is an open source development platform for building type-safe, production-ready backend applications and distributed systems. It supports Go and TypeScript, provides built-in infrastructure automation for datab… Flux (catalog) — An open-source text-to-image AI model developed by Black Forest Labs that generates high-quality images from text prompts with improved prompt following and visual quality. Frappe (catalog) — Frappe is a fully featured, low-code web framework written in Python and JavaScript that powers ERPNext, the open-source ERP for accounting, inventory, payroll, and operations. The Frappe REST API auto-exposes every D… Gravitee (catalog) — Gravitee.io is an open-source API management platform from GraviteeSource, combining a high-performance API Gateway, full-lifecycle API Management, Access Management (IAM), Cockpit (multi-environment control plane), a… Grype (catalog)...]]></content>
    <id>http://apievangelist.com/blog/2026/05/19/every-api-provider-in-my-network-that-ships-an-mcp-server-grouped-by-tag/</id>
  </entry><entry>
    <title>The Bullshit Levels Came Down at APIDays NYC</title>
    <link href="http://apievangelist.com/blog/2026/05/16/the-bullshit-levels-came-down-at-apidays-nyc/"/>
    <updated>2026-05-16T00:00:00Z</updated>
    <content><![CDATA[I am just processing what happened the last couple of days at APIDays NYC. I spent Wednesday and Thursday. I love events that I can sleep at home each night, but I’d say that APIDays NYC is my new favorite event because it is focused on APIs, has many of the usual suspects I like to see from the API realm, but also because the bullshit levels came down a little bit from last year. APIDays NYC 2025 was my first real conference since Covid. It was also where I ran into Jerome Louvel, who is my co-founder in Naftiko. Jerome shared his initial vision with me there. I was more interested in talking people I know like Jerome at the event than I was talking to any vendor. The bullshit levels of 2025 were pretty high, and I wasn’t in the mood for the whims of the irrational market, where this year I have found my peace with the irrationality, and still think it is just as dumb as I did last year, just have a thicker skin for the bullshit this year. Artificial Intelligence still dominated things, but there were fewer of the pure AI plays present, and more talks were rooted in the realities of enterprise integration of AI, not just hustling whatever you were selling with AI. People in the hallways were talking about AI, but it was a lot more pragmatic discussion and skeptical views on the realities we all face with integrating AI successfully into production. I am here for these conversations, and this type of ongoing discussions is what I am looking to drive with Naftiko Capabilities, so it fits in well with where my head is at right now, compared with last year. The anxiety about AI is still there, but people are getting used to the discourse, and seem like we are all getting kind of used to the rhetoric. It is clear that AI isn’t going away, but we’ve hit the bullshit high water mark. I am curious how far the bullshit recedes. I found the splitting of hairs around what is acceptable around what is acceptable and what is not acceptable with API to be a curious distraction. You can use it for coding, but you can’t use it for writing articles. You can use it for generating an OpenAPI, but you can’t use it for generating documentation. There was a lot of that. I am not going to be shaming anyone for using AI, but I have accepted of people shaming me for using AI. I don’t think there is any outside of it. You are using it or you aren’t, and there are no indulgences in this game. You use AI as it is, or you do not use AI. I accept many of us do not have an option. I am not looking for absolution of my sins, I accept that I am complicit in what is going on with tech. The reduced levels of AI...]]></content>
    <id>http://apievangelist.com/blog/2026/05/16/the-bullshit-levels-came-down-at-apidays-nyc/</id>
  </entry><entry>
    <title>Making the API Evangelist Network Agent-Readable</title>
    <link href="http://apievangelist.com/blog/2026/05/16/making-the-api-evangelist-network-agent-readable/"/>
    <updated>2026-05-16T00:00:00Z</updated>
    <content><![CDATA[I spent last night applying my agent-readiness playbook, first written and applied to apis.io, and now across twenty-two subdomains of the API Evangelist network. The result is end-to-end agent-readable infrastructure built on RFCs rather than vendor conventions, sitting in front of a network of static Jekyll sites that humans browse the same way they always have. This is part of my ongoing work to answer to the question: what does an agent-readable site actually look like, end to end? Every Subdomain Has a Machine-Readable Front Door Every site under *.apievangelist.com now publishes three things at well-known locations that an agent can hit before it parses any HTML: /.well-known/api-catalog — an RFC 9264 linkset, served under RFC 9727’s well-known URI. Each entry has an anchor (the resource’s canonical URL), a title, description, and zero or more of service-desc (OpenAPI / AsyncAPI URLs), service-doc (human documentation), and describedby (JSON Schema / JSON-LD). On apis.apievangelist.com the linkset has 6,310 entries — one per API across the entire network. On contracts.apievangelist.com it has 5,280 entries — one per provider. The smaller sites carry per-resource catalogs of their own. /apis.json — the site’s own machine-readable identity in my own APIs.json format. Name, description, tags, maintainers, support contact, GitHub repo. The “who are you and what do you offer” file an agent reads instead of crawling. /robots.txt — with explicit AI consent signals. Beyond the usual Allow: /, every site now publishes: Content-Signal: search=yes, ai-input=yes, ai-train=yes Content-Usage: search=y, ai-input=y, ai-train=y Search indexing, AI inference, and AI training are explicitly permitted. The Cloudflare Content Signals and IETF AIPREF formats are both included for coverage–the consent moves from my terms of service into anHTTP header an agent can parse. That is three machine-readable files times twenty-two sites — sixty-six new artifacts that didn’t exist this morning. None of them require an agent to scrape HTML to discover what the site offers. A Cloudflare Worker Doing What Static Hosting Can’t GitHub Pages does a lot of things well. It does not let you set arbitrary Content-Type headers. It does not let you inject Link headers. It does not let you content-negotiate on Accept. It does not let you read inbound signed bot headers and surface them. So I shipped a single Cloudflare Worker in front of *.apievangelist.com doing four jobs: Sets Content-Type: application/linkset+json on the /.well-known/api-catalog files. Pages serves them as text/plain otherwise, which makes the most important machine-readable file on the site look like a blob of unstructured text to a strict client. Injects RFC 8288 Link headers on every HTML response — rel=&quot;api-catalog&quot;, rel=&quot;agent-skills&quot;, rel=&quot;sitemap&quot;, and rel=&quot;alternate&quot;; type=&quot;text/markdown&quot;. Hit any page with curl -I and you can find the machine surface without parsing the page body. This is the single highest-leverage change in the whole project. Every HTML page is now self-describing for agents. Markdown content negotiation. Send Accept: text/markdown to https://apis.apievangelist.com/store/anthropic-messages-api/ and you get this back, synthesized from the catalog entry: So when you come across the Anthropic Messages API that has been profiled as part...]]></content>
    <id>http://apievangelist.com/blog/2026/05/16/making-the-api-evangelist-network-agent-readable/</id>
  </entry><entry>
    <title>83 of the Fortune 100 Have a Developer or API Portal</title>
    <link href="http://apievangelist.com/blog/2026/05/11/83-of-the-fortune-100-have-a-developer-or-api-portal/"/>
    <updated>2026-05-11T00:00:00Z</updated>
    <content><![CDATA[I spent some time this week running a complete inventory of public developer, API, and data portals across every Fortune 100 company. Combined apis.yml metadata across the api-evangelist network with web verification of every company that had no clear evidence in the index. The result surprised me a little, as I zoomed out beyond just developer portals. 83 of the Fortune 100 have a public developer, API, or data portal of some kind. That number is higher than I would have guessed if you had asked me cold. The API economy reaches deeper into corporate America than the “AWS, Stripe, Twilio, Shopify” narrative usually credits it for. But the number is also misleading, because “having a portal” covers a wide range of seriousness — and the gap between the portals that are designed for self-serve developers and the portals that are designed to keep developers out is wider than the headline rate suggests. You have to wonder what these portals say to agents? Every company below links to its portal (where one exists) and to its api-evangelist profile where I am tracking the API surface over time. Big Tech (12) Universal, mature, and the reference shape for what a developer portal looks like: Apple (profile) Microsoft (profile) Alphabet (Google) (profile) Amazon (profile) Meta Platforms (profile) Oracle (profile) IBM (profile) Cisco Systems (profile) HP (profile) Dell Technologies (profile) NVIDIA (profile) Intel (profile) Banking and Financial Services (20) The Open Banking, BaaS, and embedded-finance wave has put a developer portal in front of nearly every major US bank, insurer, and financial-data firm. These programs are larger and more mature than most public commentary reflects at first glance: JPMorgan Chase (profile) Citigroup (profile) Capital One (profile) Wells Fargo (profile) Bank of America (profile) American Express (profile) Morgan Stanley (profile) Goldman Sachs (profile) Prudential Financial (profile) TIAA (profile) MetLife (profile) AIG (profile) Allstate (profile) Liberty Mutual (profile) State Farm (profile) Progressive (profile) Nationwide (profile) Fannie Mae (profile) Freddie Mac (profile) StoneX Group (profile) Healthcare Payers and Providers (11) Most of these portals exist because of the CMS Patient Access rule and other interoperability mandates, not because the payer or provider wanted a developer ecosystem. They are FHIR-shaped and often documented through third-party aggregators (1upHealth, Onyx, Particle Health) rather than first-party, but still fit into my strategy at Naftiko: UnitedHealth Group (profile) Elevance Health (Anthem) (profile) Cigna (profile) Humana (profile) Centene (profile) HCA Healthcare (profile) CVS Health (profile) Merck (profile) Cardinal Health (profile) McKesson (profile) Bristol Myers Squibb (profile) Retail and Commerce (13) A mix of self-serve developer programs and supplier or trading-partner portals — the line between them is fuzzier here than in most other sectors: Walmart (profile) Target (profile) Best Buy (profile) Kroger (profile) Walgreens Boots Alliance (profile) Home Depot (profile) Lowe’s (profile) Albertsons (profile) Costco Wholesale (supplier portal) (profile) TJX (supplier portal) (profile) TD SYNNEX (ION API) (profile) Tyson Foods (trading partner) (profile) Sysco (profile) Airlines and Logistics (5) Air cargo and shipping have had developer programs longer than most other categories,...]]></content>
    <id>http://apievangelist.com/blog/2026/05/11/83-of-the-fortune-100-have-a-developer-or-api-portal/</id>
  </entry><entry>
    <title>Seeing MCP</title>
    <link href="http://apievangelist.com/blog/2026/05/07/seeing-mcp/"/>
    <updated>2026-05-07T00:00:00Z</updated>
    <content><![CDATA[I am talking to a number of folks about documenting their MCP servers. Others about discovering them. Others about governing them. Generally, we are mostly talking about being able to just see the MCP wave of API expansion that has occurred across your average enterprises. This expansion phase isn’t much different than previous waves of REST, GraphQL, gRPC, Websockets, and Kafka expansions–it just happened faster and wider that most of those. I published a prototype API docs that generates documentation for API, MCP, and Agent Skills side by side last week. I called the POC, “See”. I am a big fan of “seeing APIs” and “seeing integrations”. I’ve been doing about an hour of research a week into what is happening when it comes to MCP documentation, discovery, and other goings on with MCP at the core and the edges. There isn’t a lot of service or tooling for the seeing of MCP that is required for governance of APIs, and general attitudes seem to be that AI will do the seeing for us. While I am not convinced that what has helped us find and see APIs historically will translate into helping us see the next generation of APIs, but I am also not convinced that AI will help us discover and see all of our APIs, and the skills, SDKs, and clients needed to engage with those APIs. I want to clarify here–MCP is an API. I see Microsoft, Google, and others going all in on their developer education being delivered via MCP, and I suspect more of the resources that occurs within developers will be shifted to be available via MCP, with as much of the activity as we can will be driven by skills. I don’t think we will be able see what we need to see in an API-powered chat interface. And since agent’s don’t see, I know they won’t be able to see everything we need. They will help see a lot of what exists in the cracks and shadows that we couldn’t see historically with APIs, but there will be entirely new blind spots to wrestle with. I am finding some really interesting ways of seeing APIs and their properties at scale using machine-readable artifacts, which is enabled using Claude, ChatGPT, and Gemini. I will keep pushing forward automation to help discover and document APIs, as well as visualizations that help us see all of that. I am most interested in doing it in ephemeral and evolving ways, rather than the static or even dynamic ways we’ve done historically. Seeing APIs is a massively unsolved problems. We just expanded that problem 1000x with AI and MCP. Just as we were beginning to get a hadle on the governance of HTTP APIs, we’ve expanded our API sprawl using GraphQL, Kafka, gRPC, and now MCP. There is so much more to see. There is so much more work to be done. With most people’s strategy that AI will sort it out for us. I hope...]]></content>
    <id>http://apievangelist.com/blog/2026/05/07/seeing-mcp/</id>
  </entry><entry>
    <title>Wrestling With API Complexity</title>
    <link href="http://apievangelist.com/blog/2026/05/05/wrestling-with-api-complexity/"/>
    <updated>2026-05-05T00:00:00Z</updated>
    <content><![CDATA[I like wrestling with API complexity. I see endless lessons baked into how APIs have been historically done, and how we are going to keep them working to do what we need to keep moving forward. I like wrestling with APIs in similar ways that I used to set out and explore the United States in my twenties, unsure of where I was going or how I would get there. I like wrestling with APIs in similar ways that I used to do drugs, party, and travel a lot when I was younger, unsure of where I was headed or what was going to happen next. There is a certain amount of excitement and thrill that comes with exploration across these realms. Of course, there are also a lot of differences, but I find in my mind there is a Venn diagram that makes sense to me and keeps me interested in this digital layer of our world. It is enjoyable to research a space and stuff everything into your brain so you can sit back and think deeply about it. It isn’t something that many companies will invest in, but most like to tap into the results of it. I find it soothing to absorb a large scope topic, then write about it, diagram, and exercise a bit while you have this fresh knowledge in your head. I like looking through a lot of APIs and identifying the common patterns. I like evaluating how people develop and operate their APIs, so that I can learn from the patterns they employ. I enjoy doing a lot of the work others find mundane and boring because I know that when it is all combined and evaluated there are new stories and lessons in there. I will sift through an entire government agency’s website to aggregate all of their CSVs and spreadsheets just to understand what data they depend on and produce — just so I can understand where they fit in with an overall industry. I am comfortable in within uncertainty. That doesn’t mean it doesn’t give me anxiety. I can be comfortable with uncertainty but still stress about the details. I just always know that eventually I will find my way. This is what has drawn me to APIs, and what is enabling me to get lost in the pipes behind AI. It’s crazy in here. There is a lot of things that aren’t what they seem. There are a lot of mistakes you can make. I think this is where most people are stumbling right now. They just don’t know. They can’t see things. They are worried about making mistakes. I think others, like me, get a thrill out of this, but for very different reasons than I do. I think for most it is financially motivate. I’m just looking for stories. I’m just looking to understand how people see things, and understand the impact technology in general, but AI, API, and all the other acronyms being thrown at...]]></content>
    <id>http://apievangelist.com/blog/2026/05/05/wrestling-with-api-complexity/</id>
  </entry><entry>
    <title>A Roundup of US Federal Agencies and Their APIs</title>
    <link href="http://apievangelist.com/blog/2026/05/05/a-roundup-of-us-federal-agencies-and-their-apis/"/>
    <updated>2026-05-05T00:00:00Z</updated>
    <content><![CDATA[I’ve spent the better part of two decades inventorying public APIs across the U.S. federal government, and the catalog has grown to a point where it deserves its own roundup. What follows is the current state of that catalog: every federal agency I’m tracking that exposes some kind of public-facing API, RSS feed, open-data surface, or referenced internal system, indexed in machine-readable form as APIs.yml in a dedicated GitHub repository under github.com/api-evangelist. Each entry below links to that repository so you can pull the structured index, the controlled vocabulary, and where applicable the OpenAPI specs. There are 211 agencies in this snapshot, ranging from cabinet departments down through bureaus, independent commissions, inspectors general, and the research labs and museums that quietly publish some of the most useful data in Washington. The list is alphabetical, not hierarchical — the federal org chart is a fiction APIs don’t respect anyway. If an agency is missing or an API has moved, the issues queue on each repo is the right place to flag it. Administration for Community Living (ACL) Repository: https://github.com/api-evangelist/administration-for-community-living-acl- The Administration for Community Living (ACL) is part of the United States Department of Health and Human Services. ACL works to maximize the independence, well-being, and health of older adults, people with disabilities across the lifespan, and their families and caregivers. The agency administers the Older Americans Act programs, supports disability services through centers for independent living, and maintains the AGing, Independence, and Disability (AGID) Program Data Portal providing publicly accessible datasets on aging and disability programs. ACL also operates the National Institute on Disability, Independent Living and Rehabilitation Research (NIDILRR). APIs and surfaces: AGID Program Data Portal — The AGing, Independence, and Disability (AGID) Program Data Portal provides publicly accessible data from programs funded under the Older Americans Act and related disability programs. Datasets include the American Co… Administration for Native Americans (ANA) Repository: https://github.com/api-evangelist/administration-for-native-americans-ana- The Administration for Native Americans (ANA) is an agency within the Administration for Children and Families (ACF), U.S. Department of Health and Human Services. ANA promotes self-sufficiency and cultural preservation for Native Americans, Alaska Natives, Native Hawaiians, and other Pacific Islander communities by providing social and economic development opportunities through financial assistance, training, and technical assistance. ANA administers a $45 million discretionary grant program in three primary areas: Social and Economic Development Strategies (SEDS), Native Language Preservation and Maintenance, and Environmental Regulatory Enhancement. ANA data on funded projects is publicly available through data.gov and healthdata.gov. APIs and surfaces: ANA Projects Report Dataset — The ANA Projects Report dataset provides results and impact analysis for ANA-funded projects in Native American communities. Available through the data.gov and healthdata.gov catalogs, the dataset includes project sum… Administrative Conference of the United States Repository: https://github.com/api-evangelist/administrative-conference-of-the-united-states The Administrative Conference of the United States (ACUS) is an independent federal agency within the executive branch whose statutory mission is to identify ways to improve the procedures by which federal agencies administer regulatory, benefit, and other government programs. ACUS issues approximately a dozen recommendations per...]]></content>
    <id>http://apievangelist.com/blog/2026/05/05/a-roundup-of-us-federal-agencies-and-their-apis/</id>
  </entry><entry>
    <title>Within the Enterprise Mindset There Are No Solutions, Just Stories</title>
    <link href="http://apievangelist.com/blog/2026/05/04/within-the-enterprise-mindset-there-are-no-solutions-just-stories/"/>
    <updated>2026-05-04T00:00:00Z</updated>
    <content><![CDATA[I think a lot about the mindset of executive, but also the middle tiers of leadership at enterprises. This is one of the reasons I went to work at Bloomberg for the year that I did. Not that I wanted a career at that enterprise, but I wanted to understand the mindset enterprise leadership has when it comes to API integration inside and outside the enterprise firewall. I am perpetually fascinated by the technology, business, and politics of what happens at this level, and how you tell stories that will matter to this mindset. I found myself in a discussion about Moltbook, and was asked what enterprise leadership can learn from this. I crafted my response, which included a reference to Doge, and their ability to pull of data heists across government agencies. Despite referencing a congressional report on Doge activities, and citing first-hand conversation I am having with enterprise leadership in government agencies who were impacted by these decisions—I was told this was too political and not relevant to the wider AI discussion going on. This engagement reveals to me more about how the business and politics stories can be the thing that convinces enterprise leadership to open the doors to artificial intelligence. In that your politics leave you to believe what Elon Musk, Doge, and Trump are saying about government efficiencies, which causes you to lower your guard when it coms to defending your own enterprise value, resources, and work force. Government agencies are just enterprises, and I talk with leadership in these enterprises, just like I do in the private sector. For me they are the same beast, just with different customers. I like how people can tell me they aren’t related. These are the stories I look for out in the space to understand the mindset of enterprise leadership. Leadership in the C-suite changes regularly, and when this music begins everyone has to move accordingly, and when the music stops everyone has to do the best they can with what they have. Leadership within enterprises who have been there for 10, 15, or 25+ years believe this to be normal. It is just the way things are. They are so accustomed to this reality, it is me who is abnormal and not thinking normally, and understanding the way things are. So when I point out a trojan horse being invited in by the c-suite in a government enterprise, they don’t see it at all in the same category as them letting a trojan horse into their enterprise. The dissonance between sectors and industries is so fascinating. 90% of the people I talk to in enterprises feel their problems are unique. Nobody is at the scale they are. Nobody has the unique intellectual property that they have. 90% of the people I talk to can’t see the impact the internal musical chairs, as well as the external hype cycles are having on their operations. They are just doing the best they can with what they have, and...]]></content>
    <id>http://apievangelist.com/blog/2026/05/04/within-the-enterprise-mindset-there-are-no-solutions-just-stories/</id>
  </entry><entry>
    <title>Publishing Plans, Rate Limits, and FinOps for 3,837 API Providers</title>
    <link href="http://apievangelist.com/blog/2026/05/04/publishing-plans-rate-limits-and-finops-for-3837-api-providers/"/>
    <updated>2026-05-04T00:00:00Z</updated>
    <content><![CDATA[I just finished work to publish three new machine-readable artifacts — API Commons Plans &amp;amp; Pricing, API Commons Rate Limits, and a FinOps Foundation FOCUS-aligned framework across as many API providers in the API Evangelist Network that I can. That ended up being 3,837 of the 5,127 repositories in the API Evangelist GitHub network. 11,511 new YAML artifacts. What I consider to be a full Tier 1 set of 184 well-known API providers possessing the devil in the details when it comes to the business of these APIs. The Gap I Was Trying to Close For many years I have been making the case that an OpenAPI and AsyncAPI are the leading machine-readable artifacts API providers should be publishing. OpenAPI for synchronous APIs. AsyncAPI for event-driven APIs. JSON Schema for data shapes and validation. JSON-LD for vocabulary. Spectral rulesets for governance. And APIs.json to tie them all together at a known URL. What I have not been making the case for strongly enough recently, and something AI agents have made urgent, is the financial half of the API contract. The OpenAPI spec tells a consumer how to call the API. It does not tell the consumer what the call costs, what tier they are on, what their throughput allowance is, what the meter rolls up to on the invoice, or what the dimensions are that let them allocate cost back to a team, domain, or line of business. None of that lives in any of the existing machine-readable specs. For a developer building a one-off integration, the gap is fine. They read the pricing page, sign up, watch their first invoice, and learn. The discovery loop is human-paced. For an AI agent making decisions at machine speed across hundreds of providers, the gap is load-bearing. The agent can fetch the OpenAPI spec and call the right endpoint with the right parameters and get the right response — and have no idea whether that call cost a hundredth of a cent or fifty dollars. It cannot pick the cheaper of two equivalent providers. It cannot stop itself before exhausting a quota. It cannot tell its caller what the bill is going to look like over time. The fix is the same thing I have been arguing for a while now: publish the missing data as a machine-readable file, in the provider’s repo, indexed by APIs.json, alongside everything else. Three new artifact types — plans, rate limits, finops. This will help close the busienss gap I am speaking of. What Got Generated This work happened in two phases. Phase one Generated scaffold artifacts for every qualifying API provider in the API Evangelist network. A provider qualifies if its apis.yml declares at least one API in the apis: array — which matched 3,837 of the 5,127 repos. For each qualifying provider I generated three YAML files in three new directories: plans/{provider}-plans-pricing.yml — three scaffold tiers (Free, Professional, Enterprise) with placeholder limits and prices, conforming to the API Commons Plans schema. rate-limits/{provider}-rate-limits.yml — standard...]]></content>
    <id>http://apievangelist.com/blog/2026/05/04/publishing-plans-rate-limits-and-finops-for-3837-api-providers/</id>
  </entry><entry>
    <title>Artificial Intelligence Choosing My Tools and Services</title>
    <link href="http://apievangelist.com/blog/2026/05/04/artificial-intelligence-choosing-my-tools-and-services/"/>
    <updated>2026-05-04T00:00:00Z</updated>
    <content><![CDATA[While building a signup form for my new CentralPark.Guide website I was using Claude to help me deploy a Cloudflare worker to handle the submission of form and the emails that get sent to me and to end-users. As part of the setup Claude asked me to clarify one thing that I thought was worth tuning into:


  Email provider: I’ll write the Worker for Resend (simplest API, free tier, just an API key). If you’d rather use AWS SES, Mailgun, or Postmark, say so.


You can see the future of product placement and advertising here. Advertisers and AI providers have a lot of data. It seems like the next frontier. I am morbidly fascinated with how this will work, and like the rest of the train wreck that is the API realm—I won’t be able to help myself when it comes to tuning in.
]]></content>
    <id>http://apievangelist.com/blog/2026/05/04/artificial-intelligence-choosing-my-tools-and-services/</id>
  </entry><entry>
    <title>We Standardized the API. We Didn't Standardize the Application.</title>
    <link href="http://apievangelist.com/blog/2026/05/01/we-standardized-the-api-we-didnt-standardize-the-application/"/>
    <updated>2026-05-01T00:00:00Z</updated>
    <content><![CDATA[During my Thursday office hours this week I explored adding applications and obtaining keys for six developer portals back to back: Notion, Slack, LinkedIn, GitHub, Cloudflare, and Google. Here was my plan — create an application against each one, the same way any developer would when wiring a new integration. I had Claude open in a side panel as a co-tracker, capturing every URL, every form field, every required input, every gating dialog. Three hours later I had a map of what it actually takes to onboard six common APIs (out of the hundreds we use). Seeing the Diff Between Every provider exposes the same conceptual thing: a configurable “application” that holds the credentials, scopes, and metadata required to consume their API. None of the providers call it the same thing. None of them shape it the same way. None of them gate it on the same conditions. None of them export it in the same format. Notion calls it an “internal connection.” It has a single Configuration page with capability checkboxes (read content, update content, insert content, read comments, insert comments, user info), a Content Access tab where you select individual pages and teamspaces, and a single installation access token. There is no client ID, no client secret, no verification gate. For internal use it’s the cleanest shape of the six providers I dug into. Slack calls it an “App.” Slack has the largest surface area of any provider in this research, with seventeen distinct configuration pages spread across two host domains, three sidebar groups (Settings, Features, Submit to Marketplace), and two scope namespaces (bot token vs. user token). It has a Socket Mode option that routes events over WebSockets instead of public HTTP. It has a Block Kit framework for app home tabs. It has a JSON or YAML manifest that exports the entire app config, and that manifest is the most agent-friendly artifact across all six providers. No one else has anything like it. LinkedIn calls it an “App,” gated behind a “company-page verification” flow you complete by sending a magic URL to a Page Admin who has thirty days to act. Your scopes are not free-form — they are bundled inside “products” (Default tier, Standard tier, Development tier) and only the Default tier products are available without verification. The default access token TTL is sixty days. If you accidentally type a personal profile URL into the LinkedIn Page field instead of a Company Page URL, the form lets you submit and then warns you it cannot be undone. GitHub gives you two completely separate paths. Personal Access Tokens, 1) fine-grained or classic are the path of least resistance for any application: name, expiration, repos, permission matrix. OAuth Apps are the path for multi-user or distributed scenarios: client ID, client secret, callback URL, optional Device Flow toggle. There is no verification gate on either. There is also no auto-cleanup; my own account had expired tokens piling up and one with no expiration date at all, which is...]]></content>
    <id>http://apievangelist.com/blog/2026/05/01/we-standardized-the-api-we-didnt-standardize-the-application/</id>
  </entry><entry>
    <title>A Bridge Between Human and AI on Your Documentation</title>
    <link href="http://apievangelist.com/blog/2026/05/01/a-bridge-between-human-and-ai-on-your-documentation/"/>
    <updated>2026-05-01T00:00:00Z</updated>
    <content><![CDATA[Someone on LinkedIn told me to look at how AssemblyAI approaches their documentation after I shared a link with an API / MCP / Skills documentation prototype I had developed. AssemblyAI is a platform for building Voice AI applications, but it is the button in the top right hand corner of their documentation page that I think reveals a step forward in how we are communicating within our developer portals.

At the top of each page is a “Copy Page” button, but when you look closer it has a drop-down that gives a set of options that reflect the changing landscape in how we engage with our developers. There are seven options available for each page.


  Copy Page — Copy this page as Markdown for LLMs.
  Ask a question — Chat with an AI assistant.
  View as Markdown — View this page as plain text.
  Open in Claude — Ask questions about this page.
  Open in ChatGPT — Ask questions about this page.
  Connect to Cursor — Install MCP server on Cursor.
  Connect to Claude Code — Copy MCP server command for Claude Code.


The copy page, from a context engineering perspective is key. The ability to ask a question via assistant isn’t that novel, but with more context it moves things forward a bit. The view as markdown is showing the entropy occurring across our portal content. Then the open in Claude, Claude Code, ChatGPT, and Cursor provide the next generation client and interface.

I have been exploring what the agentic front door looks like for any domain, pushing forward apis.io when it comes to robots.txt, sitemap.xml, MCP, Agent Skills and more, but this is the human to copilot bridge primarily. I will need to think through more the overlap of protocols here, but how the automated agent and human in the loop, or human led engagement within portals, with our APIs, and how I can best inject Naftiko, API Evangelist, and APIs.io into the stream of consciousness happening here.
]]></content>
    <id>http://apievangelist.com/blog/2026/05/01/a-bridge-between-human-and-ai-on-your-documentation/</id>
  </entry>
</feed>
