---
title: Making the API Evangelist Network Agent-Readable
url: http://apievangelist.com/blog/2026/05/16/making-the-api-evangelist-network-agent-readable/
date: '2026-05-16'
author: ''
feed_url: https://apievangelist.com/atom.xml
---
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="api-catalog", rel="agent-skills", rel="sitemap", and rel="alternate"; type="text/markdown". 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...