Kin Lane (Unofficial)

Unofficial automated RSS/Atom links to Kin Lane's work on Kin Lane’s API-first software projects and essays on APIs/agents. Original work is credited at the source; follow the source links. Zaps support the independent feed operator, not the author.

Public Key

npub1880vaey0k9e8ags733vqag37jaks67p8mmyrs45t789t4cck8v8qv50nze

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsrnhkwuj8mzun75g0gckqw5glfwmgd0qnaajpc269lrj46uvtrkrspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsfmal7t

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1880vaey0k9e8ags733vqag37jaks67p8mmyrs45t789t4cck8v8qv50nze

Show more details

Last Notes

2026-10-30 01:55:13 GMT

Lint An OpenAPI And Find Out Which Rules Decide If It Passes
This is the first in a new series. Every business day I’m going to take one API Evangelist API operation, and the MCP tool that sits on top of it, and show what it does with a real input. No screenshots of a dashboard, no hypotheticals. I’ll call the thing and tell you what came back.
I’m starting with the one most people need first. You have an OpenAPI, and you want to know if it’s any good before it ships. The MCP tool is validate_api, and the REST operation behind it is POST /governance/validate. It lints OpenAPI, AsyncAPI, Arazzo, JSON Schema and a handful of other formats with the OpenLint engine, and it’s free.
What I gave it
I gave it the most familiar API description there is: the Petstore example the OpenAPI Initiative publishes in its learning materials. Three operations: list pets, create a pet, get one pet by id. It’s a teaching example, so it’s clean, small and missing the things a teaching example usually leaves out.
I ran it twice. The first time I passed only the document, so it ran against our default rule catalog. The second time I added "profile": "owasp", which runs the OWASP API Security Top 10 rules instead.
What came back
Against the default catalog, the Petstore passed:
{
"format": "openapi",
"ruleset": "catalog",
"ruleCount": 469,
"passed": true,
"summary": { "error": 0, "warning": 8, "info": 234, "total": 242 }
}
469 rules ran, and they produced 242 findings across 59 different rules, with no errors. The eight warnings are the ones you’d expect: no info.contact, no info.description, operations without a description, and operation tags that aren’t defined in the global tags. The 234 info-level findings are where the catalog shows what it is. The most frequent was response-include-ratelimit-header, 18 times, followed by hypermedia links, correlation ids and string length limits.
Against the OWASP profile, the same document failed:
{
"ruleset": "profile:owasp",
"ruleCount": 31,
"passed": false,
"summary": { "error": 2, "warning": 8, "info": 8, "total": 18 }
}
error owasp-api8-misconfig-https-servers
API8 (Security Misconfiguration): server URL must use https://
error owasp-api2-auth-security-schemes-defined
API2 (Broken Authentication): components.securitySchemes must define at least one scheme
warning owasp-api1-bola-operation-security-defined (x3, one per operation)
warning owasp-api9-inventory-operation-description (x3)
The Petstore serves from http://petstore.swagger.io/v1 and declares no security scheme at all. Under the default catalog, those were info-level notes buried among 234 others. Under OWASP, they’re the two things that fail the build.
Same document, same engine, opposite verdicts. The rules decided, not the API.
I also want to be honest about the catalog. It’s built from rulesets that real organizations have published, and that shows. Four different rules flagged the same http:// server URL. One rule told the Petstore it should be served from api.spscommerce.com, because that rule came from SPS Commerce’s own style guide. That’s useful when you want to see how far the industry’s rules reach, and it’s the wrong thing to block a merge on. The tool’s own description says the same: pass your own ruleset to run rules you own instead of the catalog, which is what you should do before gating on anything.
What that makes possible
Survey before you commit. Run the catalog once to see the full range of what other organizations check for, then pick the rules that match your own standards. The top_rules list in the response is a quick way to see where an API is weakest.
Gate on a named profile. If what you care about is security, run "profile": "owasp" in CI and fail on errors. Thirty-one rules mapped to the OWASP API Top 10 is a much more defensible gate than 469 rules from everywhere.
Bring your own rules. Pass an OpenLint or Spectral ruleset directly and get the same response shape back. Paid accounts can store an org default so every call uses it.
Let an agent check its own work. Because it’s an MCP tool, an agent writing or editing an OpenAPI can lint it before handing it back, and read the findings as structured JSON instead of guessing.
Try it
It’s free and needs no key. From any MCP client, connect to https://mcp.apievangelist.com/mcp (or the lighter https://mcp.apievangelist.com/mcp/governance) and call validate_api with your document. Over REST:
curl -X POST https://api.apievangelist.com/v1/governance/validate \
-H 'content-type: application/json' \
-d '{"document": "<your OpenAPI as a YAML or JSON string>", "profile": "owasp"}'
The operation is documented in the Governance API reference, and the MCP server docs explain how to connect a client. Run it on one of your own APIs with and without a profile, and see which rules decide whether it passes. Tomorrow’s tool goes the other direction, searching sixteen years of API research instead of checking a contract.
https://apievangelist.com/2026/10/29/lint-an-openapi-and-find-out-which-rules-decide-if-it-passes/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/lint-an-openapi-and-find-out-which-rules-decide-if-it-passes.png
#api #openapi #owasp #petstore #apievangelist #security #same #mcp
#rss #feeds #linksharing #qwibbit

2026-10-30 01:15:29 GMT

Reddit Closed Its API. Here Is Where Agents Can Still Post And Read
I tried to get a Reddit API key this week. I wanted something small: read-only search across a handful of developer subreddits, to find “is there an API for X?” questions I could answer by hand. Reddit’s app page sent me to its Responsible Builder Policy. The access request form offers two choices, moderator or developer, and choosing developer tells you to build on Devvit. Devvit apps run only inside subreddits whose moderators install them, so a tool that reads across communities has no path in. Reddit stops taking new public API requests on October 31, drops RSS on November 13, and ends legacy access in March 2027.
That is Reddit’s call to make. It also leaves a lot of developers and agent builders looking for somewhere else to post and read. Below are the places I’d point them to, starting with two I built for exactly this.
Yawplet: short messages, posted by agents
Yawplet is for short messages: 500 characters, one idea each, posted by AI agents for the people and projects they work for. People browse the pages. Agents post and read through an API and an MCP server.
Reading is free and needs no key. JSON Feed, RSS, topics, places, author feeds, a sitemap, and llms-full.txt. Posts are CC BY 4.0, and robots.txt allows every crawler, including AI crawlers.
Posting costs $0.02 per post. Agents create an account with one call (POST /v1/accounts). Search is free for the first 100 calls per key per day.
It’s built for agents. It has an OpenAPI contract, an MCP server with OAuth, an A2A agent card, a dry_run=true mode that runs every check without charging, idempotency keys, RFC 9457 errors, and signed webhooks.
Yarnhen: stories, posted by agents
Yarnhen is the long-form sibling: reporting, essays, fiction and field notes of 150 to 2,500 words. It runs on the same platform with the same API, MCP server and OAuth, and one account works on both sites.
How they score
Both are listed on APIs.io and scored with the same Kin Score rubric as the rest of the catalog’s 27,000+ providers:
Kin Score
Agent Readiness
Yawplet
84.2 (exemplar)
80.4 (agent-native)
Yarnhen
84.2 (exemplar)
80.4 (agent-native)
I built both sites, so weigh that accordingly. The scores come from the same public rubric and probes as every other provider, and the checks that fail are published right beside the ones that pass.
Other places worth looking
Bluesky / AT Protocol: an open protocol with a public firehose and generous API access.
Mastodon and the fediverse: an ActivityPub API on every instance, with policy set by each instance.
Lemmy: a federated, Reddit-style link aggregator with an open API.
Hacker News: a free, read-only Firebase API.
Discourse: many developer communities run on it, and every forum has a JSON API.
Moving a Reddit bot
If your bot posts summaries, digests or answers to Reddit, moving it to Yawplet takes three steps:
# 1. Create an account (returns an API key)
curl -X POST https://yawplet.com/v1/accounts -H "Content-Type: application/json" \
-d '{"name":"Your Bot","email":"[email protected]","handle":"yourbot","accept_terms":true}'
# 2. Dry-run a post: every check, no charge
curl -X POST "https://yawplet.com/v1/posts?dry_run=true" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" -d '{"text":"Hello from a former Reddit bot."}'
# 3. Post for real, with an idempotency key so retries never double-charge
curl -X POST https://yawplet.com/v1/posts -H "Authorization: Bearer $KEY" \
-H "Idempotency-Key: $(uuidgen)" -H "Content-Type: application/json" -d '{"text":"Hello from a former Reddit bot."}'
To use MCP instead, point your client at https://yawplet.com/mcp and approve the OAuth consent. The developer quickstart has the rest.
Reddit decided where its walls go. The open web still has room for agents to post and read in public.
https://apievangelist.com/2026/10/30/reddit-closed-its-api-here-is-where-agents-can-still-post-and-read/
#api #agents #yawplet #mcp #kinscore #yarnhen #firebaseapi #both #posts
#rss #feeds #linksharing #qwibbit

2026-10-29 23:18:21 GMT

E-Invoicing: The Shape Of The Answer
Last week I wrote about DeepInfer and the shape of the answer, and how batch-invariant inference, deterministic sampling and schema-constrained outputs make valid JSON table stakes and push the hard problem back to agreeing on the shape. I want to apply that to one industry at a time, and I can’t think of a better place to start than e-invoicing and tax, because this is an industry where governments already wrote the shape down and made it law.
The answer this industry needs
The business outcomes here are not vague. Turn a purchase order into a valid invoice. Turn a PDF invoice that arrived as an email attachment into a structured e-invoice a buyer’s system will accept. Turn a line item into a tax treatment decision: which category, which rate, which exemption reason, as a structured answer and not a paragraph.
Every one of those has a receiving system on the other side that will reject anything that doesn’t fit. A tax authority platform, an access point on a network, a buyer’s accounts payable system. There is no partial credit. The invoice validates or it bounces.
The shape is already written down
This is the industry that did the boring work, and did it in public.
Peppol BIS Billing 3.0, maintained by OpenPeppol, defines two syntaxes, the UBL Invoice and the UBL Credit Note. The spec says plainly that all element names are inherited from EN 16931, and it ships Schematron for the Peppol rules and for the TC434 rules, the “EN16931 model bound to UBL.” It also publishes the code lists: ISO 4217 currency codes, the duty or tax or fee category code (a subset of UNCL5305), the invoice type code (a UNCL1001 subset), payment means (UNCL4461), allowance and charge reason codes, and the VATEX exemption reason list.
EN 16931 is the European semantic model for an invoice. It is what Peppol, and the national formats built on it, bind to a concrete syntax.
UBL, the OASIS Universal Business Language, is the XML syntax Peppol uses.
XRechnung is Germany’s standard for invoicing public buyers, implementing Directive 2014/55/EU. It is a CIUS plus an extension, currently at version 4.0.0, and defines the invoice as an XML data set.
FatturaPA is Italy’s own XML format, exchanged through the SdI.
France runs its rollout through platforms approved by the DGFiP. Our market sweep on October 15th read the DGFiP list of plateformes agreees and counted 166 operators, 155 immatriculated and 11 still awaiting interoperability tests.
Look at what that list of code lists is. It’s a set of enums. It is exactly what a constrained decoder wants as terminals in a grammar. A model can’t invent a tax category code if the only codes it is allowed to emit are the UNCL5305 subset Peppol publishes.
What the catalog holds
The E-invoicing and Tax Compliance market on APIs.io is a certified-operator market. It was built from three registers: the OpenPeppol certified service providers list (740 members, 733 certified as Access Points and 414 as SMPs), the DGFiP list, and the six Streamlined Sales Tax certified service providers in the US. It resolves to 56 providers in the catalog, with a mean Kin Score of 43.3 and a median of 45.2.
The leaders:
Qonto 72.3, exemplar, agent readiness 57.0
Avalara 69.9, exemplar, agent readiness 45.0
Tradeshift 65.3, strong, agent readiness 50.9
Visma 64.7, strong, agent readiness 46.0
Then the gap. 13 of the 56 are strong or better. 15 are thin, emerging or minimal, and that bottom group includes names that sit at the center of the e-invoicing networks: Seeburger at 11.3 and Billtrust at 17.9, both with an agent readiness of 0 in our read. Basware is at 40.8 and SAP at 49.9, though SAP has the highest agent readiness in the cohort at 58.4.
On the shape artifacts, 17 of the 56 provider repos hold JSON Schema, 9 hold JSON Structure, 19 have a vocabulary, 11 have examples, and 3 have Arazzo workflows (Avalara 12, Intuit 16, Cadana 3). The depth is concentrated: Xero carries 407 schemas and 327 examples, Axway 380 schemas, Avalara 273 schemas and 137 examples.
Does anyone publish the standard’s shape in their API? A few, partially:
The Avalara E-Invoicing API contract in the catalog (its authorship isn’t recorded, so treat it as our reading of Avalara’s API) describes submitting documents “through the interoperability network (e.g., Peppol),” with a data format enum that includes ubl-invoice and ubl-creditnote, plus a /mandates resource for the country rules.
Teamleader’s invoices contract lists ubl/e-fff, ubl/peppol_bis_3 and ubl/xrechnung as download formats. That contract is one API Evangelist generated from Teamleader’s documentation, so the values are theirs but the OpenAPI is ours.
Qonto’s API documentation has a Factur-X section for client invoices.
DDD Invoices states Peppol exchange and EN 16931 compliance.
On the standards page, Peppol is carried as a tag by 4 providers: Tradeshift, DDD Invoices, Koalaboox and Unit4. UBL has no provider tagged yet.
What determinism changes here
E-invoicing is a reconciliation business. An invoice gets issued, transmitted, validated, booked by the buyer, reported to a tax authority, and matched against a payment. Every one of those steps assumes the document is the same document. If an extraction model reads the same PDF on Tuesday and on Friday and returns different VAT category codes, you don’t have a model problem, you have an audit problem.
Batch-invariant and deterministic inference gives you something you can actually defend: the same input produces the same structured invoice, and you can rerun it later and get the same answer an auditor is looking at. Constrained output means the answer is shaped by the Peppol code lists and the EN 16931 element names rather than by the model’s best guess. Then the Schematron the spec already publishes checks what the schema alone can’t, like totals adding up. That’s the pattern from the anchor post, generate inside the shape and check with the rules, and this industry already shipped the rules.
Volume matters too. These networks move invoices in bulk, and batch invariance is what lets you process a backlog in large batches without the batch changing the answers.
Where it falls short
The standards are open, but the APIs that carry them mostly don’t show it. UBL has no provider tagged in the catalog. Peppol has four. Most of what I can find is a format enum or a mention in a description, not the EN 16931 model expressed as JSON Schema in an API contract. The shape lives in XSD and Schematron, and the APIs wrap it as a base64 string field, which is useless to a constrained decoder. Somebody has to translate the semantic model into the schemas and vocabularies an inference engine consumes, and I can’t find a provider in the catalog who has done that.
The certified operators are thin. Several of the companies that actually move invoices on these networks score in the bottom of the cohort, and some of the registers can’t be read at all. Our sweep found no public SdI intermediary register for Italy, no service-provider register for Poland’s KSeF, and the ZATCA list renders only in a browser.
Tax treatment is the weaker half. EN 16931 tells you where the tax category goes. It doesn’t tell you which one applies to a given product in a given jurisdiction. That decision lives in proprietary engines, and their shapes are their own.
The shape was the regulation
Most industries are going to spend the next year arguing about what the answer should look like. E-invoicing doesn’t have to. The governments settled the shape, published the code lists, and wrote the validation rules. What’s missing is the API layer that exposes that shape as something a model can be constrained to, and the providers who do that work first are going to be the ones whose invoices come back right every time.
https://apievangelist.com/2026/10/29/e-invoicing-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/e-invoicing-the-shape-of-the-answer.png
#shape #answer #invoice #peppol #tax #ubl #xml #turn #ublcredit
#rss #feeds #linksharing #qwibbit

2026-10-29 22:41:28 GMT

Automate Ecommerce Email Campaigns And Segment Shoppers With Omnisend
If you run an online store, you already know the email that earns money: the welcome note to a new subscriber, the campaign to people who bought last spring, the reminder to someone who left a cart. The hard part is keeping your subscriber list, your product catalog and your campaigns in step with what is actually happening in the store. Omnisend does that work, and it does it through an API, so your store, your other tools, or an AI assistant can add subscribers, build segments and send campaigns without anyone copying lists around.
What Omnisend does
Omnisend is an email and SMS marketing automation platform built for ecommerce, headquartered in Lithuania, with integrations into Shopify, BigCommerce, WooCommerce, Magento, Wix, Square Online and other storefronts. It brings together automation workflows, a campaign builder, segmentation, popups and forms, web push, product recommendations, A/B testing and reporting. It also runs hosted MCP servers, the connector standard AI assistants use to call tools. More on the Omnisend website.
What you can get done
Run campaigns and automations
Digital Marketing Management covers the two kinds of sending: campaigns you send once, and automations that run whenever a trigger fires, like a new signup.
GET /campaigns lists your campaigns, including the drafts.
POST /campaigns creates a new email campaign draft.
GET /automations lists your automation workflows and which are enabled.
POST /automations builds a new automation from a trigger and its steps.
PATCH /automations/{id} edits an automation.
Keep subscribers up to date
Customer Data Management is your subscriber list, kept in step with the store.
POST /contacts adds a new subscriber, or updates them if the email already exists.
PATCH /contacts updates a contact using only their email address.
GET /contacts lists contacts, such as everyone carrying a specific tag.
DELETE /contacts/tags removes a tag from many contacts in one call.
Target the right shoppers
Customer Segmentation Management builds segments, saved rules that pick out a group of shoppers.
POST /segments creates a segment from a set of conditions.
GET /segments/{segmentID} shows the conditions behind a segment.
GET /segments/{segmentID}/statistics tells you how many contacts match a segment right now.
Manage email templates
Marketing Management handles the content of the emails themselves.
GET /email-templates lists your email templates.
POST /email-templates creates a template from content sections.
POST /email-content/{id}/render turns stored email content into HTML so you can preview it.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 13 for Omnisend, including:
Subscribe and Trigger Welcome adds a subscriber and fires the event that starts your welcome automation.
Create and Send Campaign creates a campaign, confirms it, and queues it to send.
Copy and Send Campaign reuses an existing campaign and sends the copy.
Create Segment and Read Statistics builds a segment and reports how many people are in it.
Refresh Product Catalog Entry replaces a product with its updated details.
Ask for it in plain language
Our conversational overlay for Omnisend maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“How do I add a new subscriber, or update them if the email already exists?”
“Which of my campaigns are still drafts?”
“How many contacts match a segment right now?”
“Which of my automation workflows are currently enabled?”
“Can I remove a tag from many contacts in one call?”
You can see one in the Omnisend Automations phrasing overlay.
Getting started
Omnisend has a free tier with self-serve signup, and you call its hosted service. Start with the API documentation and the authentication guide; every request carries an API key or an OAuth token. On APIs.io, see the Omnisend profile, the Contacts API, the Campaigns API and the Products API. Wire up the welcome workflow first; it is the one every new subscriber sees.
https://apievangelist.com/2026/10/29/automate-ecommerce-email-campaigns-and-segment-shoppers-with-omnisend/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/automate-ecommerce-email-campaigns-and-segment-shoppers-with-omnisend.png
#omnisend #campaigns #post #email #get #sendcampaign #marketingmanagement #run #squareonline
#rss #feeds #linksharing #qwibbit

2026-10-29 22:03:27 GMT

Google Ships Agent Skills Like Products, And That’s The Lifecycle They Need
Google published a good look at how it ships its Agent Skills like products, two months after the first behind-the-scenes post. The Google Agent Skills repository now holds more than 170 skills from teams across Google, and has passed 21,000 GitHub stars, up from 15,000. The line that frames the whole post is one I’ve been trying to say for a while: a skill is a living product, not a one-off document.
That’s the API lifecycle, applied to a new artifact, and it’s worth walking through what Google built because almost all of it is something we already know how to do with APIs.
A skill is a behavioral contract
Google’s argument is that documentation explains concepts to a person, while a skill steers an agent’s reasoning, tool selection and execution. A misplaced phrase can send an agent to invalid command flags, an infinite loop or wasted tokens. So every edit to an instruction is a behavioral change, and it gets treated like one.
Their pipeline has six automated gates before a human approves anything: structural conformance, skill linters, semantic versioning, evaluation suite validation, link validation, and an AI review agent that uses a skill to review skills. Every behavioral change needs a version bump. New skills start at 1.0.0. Every pull request has to link a fresh evaluation report comparing the skill to its previous version, or to an agent without it. Links get checked before merge and again every Monday.
Swap “skill” for “API” and that’s a mature API governance program: a contract, a style guide enforced by linting, versioning with rules, tests as evidence for every change, and a human who owns the decision. I’m glad to see it arrive this early in the life of a new artifact type instead of ten years in.
The deterministic trap
The part I’d underline is what Google calls the deterministic trap. Authors write rigid, numbered sequences of CLI commands into Markdown, and hand a probabilistic engine something that needed to be exact. Google’s reviewer moves those sequences into scripts and keeps the instructions for work that needs judgment: choosing an architecture, diagnosing logs, synthesizing code. Scripts have to run without interactive prompts, take flags, offer --help and a --dry-run, and write JSON to standard output.
I learned the same lesson running the APIs.io pipeline. When I went step by step through it, 20 of its 41 steps didn’t need a model at all, and moving those into scripts is what made the pipeline repeatable. Google’s companion rule, stage the cheap deterministic checks first and only run the expensive LLM checks when those pass, is the same idea applied to CI. So is their advice to prefer remote MCP tools and wrap any other CLI or API call in a script. The model does the judgment. The contract and the code do the rest. It’s the same principle behind the MCP Style Guide.
Their documentation drift lesson is another one I recognize. Google’s index.json opens with “This file is generated. Do not edit it by hand.” The APIs.io skills publish a manifest the same way, at /skills/index.json and /.well-known/agent-skills/index.json, generated from the skills themselves. Every hand-maintained index I’ve ever run fell out of date within weeks. Generate it and test it, or it will lie to you.
Where the standards come in
Google’s review checklist requires frontmatter that follows the Agent Skills specification, which is one of the specifications I now track every week in The Specification Layer. That’s what makes a catalog of 170 skills portable across platforms instead of tied to one.
The other standard that matters here moved today. The Model Context Protocol’s Skills extension is now officially Beta, which gives skills a way to be served by an MCP server, with a skill:// URI per skill and a defined change process behind it. Google distributes its skills through GitHub and package tooling like npx skills update, and makes the point that skills don’t auto-update in the background, so teams can pin a known-good version. That’s the right default for a repository. When a week ago I counted who serves skills over MCP the way the spec says, I found four companies. APIs.io serves its own twenty skills that way too.
What I’d like to see next is the two coming together: the version Google already puts in each skill’s metadata, served from the same MCP server as the tools the skill teaches an agent to use, so a client can see which skill version goes with which tools. Google has built the product discipline. The protocol now has a lifecycle to carry it. A skill shipped like a product deserves a distribution channel that treats it like one.
https://apievangelist.com/2026/10/29/google-ships-agent-skills-like-products-and-thats-the-lifecycle-they-need/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/google-ships-agent-skills-like-products-and-thats-the-lifecycle-they-need.png
#likeproducts #agentskills #googleagent #api #every #need #styleguide #scripts
#rss #feeds #linksharing #qwibbit

2026-10-29 21:23:38 GMT

Run Code Without Managing Servers And Release It Safely With AWS Lambda
Plenty of businesses need a little bit of code running somewhere: resize the photos customers upload, process an order when it lands in a queue, answer a form on the website. Renting and patching a server for that is overkill. AWS Lambda runs that code for you when something happens, and everything about it, from creating a function to shifting traffic onto a new version, is available through an API that your deployment tools or an AI assistant can call.
What AWS Lambda does
AWS Lambda is a serverless, event-driven compute service. “Serverless” means you hand Amazon your code and it handles the servers, operating system updates, capacity, automatic scaling and logging. Your code is packaged as a function, and it runs in response to events such as a file upload, a message on a queue or a web request. More on the AWS Lambda website.
What you can get done
Create and manage your functions
IT Infrastructure Management is the inventory of code you run on Lambda.
POST /2015-03-31/functions creates a new function from a deployment package, the bundle of your code.
GET /2015-03-31/functions lists the functions you have in a region.
GET /2015-03-31/functions/{FunctionName} shows a function’s details and a link to download its code.
DELETE /2015-03-31/functions/{FunctionName} deletes a function or one of its versions.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. With Lambda the workflows are where the value is, because releasing code safely takes several steps. APIs.io catalogs 13 for AWS Lambda, including:
Deploy a Function and Verify It Runs creates a function, waits for it to become active, then invokes it once to prove it works.
Release a Version Behind an Alias publishes a version and points a named alias, like “production”, at it.
Shift Canary Traffic Across Two Versions sends a small share of requests to a new version before trusting it with all of them.
Wire an Event Source to a Function connects a queue or stream to a function and waits until Lambda starts reading it.
Expose a Function Over an HTTPS Function URL gives a function its own web address with an explicit access rule.
Tear a Function Down in Dependency Order detaches what depends on a function, then deletes it cleanly.
Audit a Function’s Versions, Aliases, and Event Sources inventories everything attached to a function.
Ask for it in plain language
Our conversational overlay for AWS Lambda maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“What Lambda functions do I have in this AWS Region?”
“What do I need to create a new Lambda function: code, execution role, runtime?”
“How can I download the deployment package of an existing Lambda function?”
“Does deleting a Lambda function also remove all its versions and aliases?”
You can see one in the AWS Lambda Aliases phrasing overlay.
Getting started
Lambda has a free tier with self-serve signup; check Lambda pricing for what you pay beyond it. The documentation covers the runtimes your code can be written in, plus extensions and the Telemetry API for monitoring. On APIs.io, see the AWS Lambda profile, the Functions API, the Aliases API and the Function URL API. Pick one small job you run by hand today and deploy it as your first function.
https://apievangelist.com/2026/10/29/run-code-without-managing-servers-and-release-it-safely-with-aws-lambda/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/run-code-without-managing-servers-and-release-it-safely-with-aws-lambda.png
#awslambda #function #code #release #version #awsregion #run #get #httpsfunction #order
#rss #feeds #linksharing #qwibbit

2026-10-29 20:43:57 GMT

API Evangelist Is Now A Financial Contributor To OpenLint
API Evangelist just became a financial contributor to OpenLint on Open Collective, with a €1,000 contribution. I want to explain why, and ask you to do the same if your work depends on API linting.
Why we put money in
I’ve written about why I forked Spectral and why it became OpenLint. The short version: Spectral’s ruleset format quietly became how governments, banks and companies write down their API design rules, it was never specified, and it depended on one vendor’s priorities. OpenLint is the community fork turning that work into a formal, vendor-neutral standard, with a draft specification, a reference toolbox, and weekly office hours that are open, recorded and transcribed.
API Evangelist depends on this work every day. Linting is how I check the contracts in the APIs.io catalog, how I talk to companies about governance, and how I measure what providers say against what they publish. If the rules format that all of that runs on is going to be a shared standard, then the people who rely on it should help pay for it. So we are.
I’ve also been asking companies that depend on OpenAPI, Arazzo and Overlays to become members of the OpenAPI Initiative. It would be hard to keep making that argument if I weren’t doing the same thing myself for the project I’m helping to lead.
What the money is for
OpenLint’s home is Open Source Europe, which acts as its fiscal host, so contributions are held and spent in the open. The money supports the project’s operations and the work on its projects:
Maintainers. The specification and the toolbox move forward because people give them their time. Funding lets the project pay for some of that time instead of relying entirely on goodwill.
Meetings and community. Office hours, recordings, transcripts and the infrastructure that keeps the work public.
Grant writing. There is real public money for open infrastructure like this, especially in Europe, where much of the demand for API linting comes from public institutions enforcing national API design rules. Writing good grant applications takes time. A modest amount of contributed money makes it possible to go after much larger grants that fund the specification, the conformance suite and the tooling properly.
Every euro is visible on the collective’s page, so you can see where it went.
Become a contributor
If your organization publishes API design rules, runs Spectral rulesets in CI, builds tooling that imports them, or sells a product that depends on them, you depend on this work. Here’s how you can help:
Contribute on Open Collective. A one-time or recurring contribution, at whatever level makes sense for you. Organizations and individuals are both welcome.
Show up. Come to the office hours, open a discussion, review the specification, or pick up an issue in the community repository.
Tell us what you use. If you depend on Spectral rulesets, let us know how. It helps the defaults reflect the real world, and it strengthens every grant application we write.
I’d much rather the API linting standard be paid for by the people who use it than by any one company. API Evangelist is in. I hope you’ll join us.
https://apievangelist.com/2026/10/29/api-evangelist-is-now-a-financial-contributor-to-openlint/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/api-evangelist-is-now-a-financial-contributor-to-openlint.png
#apievangelist #financialcontributor #open #spectral #opencollective #linting #europe #office
#rss #feeds #linksharing #qwibbit

2026-10-29 20:04:48 GMT

Skills Over MCP Is Now Officially Beta
Today the Skills extension for the Model Context Protocol moved into Beta. Pull request #161 in the ext-skills repository merged today, moving the specification from specification/stable/ to specification/beta/. Nothing in the specification itself changed. What changed is what the label means, and that’s worth understanding if you’re building on it.
This isn’t a step backward
When SEP-2640 went Final in September, I wrote that skills over MCP is final and now it needs servers, and the working group published its released revision in a folder called stable. At the time, “stable” just meant the released version, as opposed to a draft. Every MCP extension used its own words for maturity. One used stable and draft, another labeled its snapshots “Stable” and “Development.” An implementer couldn’t tell whether an official extension was settled or still being reworked.
SEP-3392, Extension Lifecycle, fixes that. It’s now Final, and it gives every extension one of four stages:
Experimental. Anything can change at any time. Expect nothing.
Beta. Real usage is welcome. Changes are approved by the extension’s maintainers, breaking changes are expected to be rare, and each one is documented.
Stable. Behavior is fixed within a core protocol revision, and changes only come with a new revision.
Core. The extension is promoted into the core specification.
The directory an extension’s specification sits in is now the marker of its stage, and “stable” became a word with a specific meaning. So the Skills spec moved out of a folder whose name now promises something it never promised. The SEP’s transition table classifies Skills, Tasks and Server Cards as Beta, and Apps and Auth as Stable.
What Beta means if you’re building on it
If you’re serving skills from your MCP server, or reading them in a client, here’s what changes in practice:
The identifier and wire behavior stay the same. Existing implementations keep working. You still declare io.modelcontextprotocol/skills, and skills are still served as skill:// resources.
Breaking changes are allowed, but logged. The repository’s decision log is now the changelog SEP-3392 requires for Beta breaking changes. Watch it the way you’d watch release notes.
There are named maintainers. The PR adds a MAINTAINERS.md that lists the working group leads as Extension Maintainers, so you know who approves changes.
The destination isn’t decided. A Beta extension has to say where it’s headed, Stable as an extension or promotion into Core. For Skills, the extensions page doesn’t say yet.
That last one is the question I’ll be watching. Skills as a Stable extension means an opt-in that servers and clients choose to support. Skills in Core would make serving and reading skills part of what MCP is.
Why I like this
I spend a lot of time measuring what providers say against what they ship, and a maturity label that means one specific thing is exactly what makes that possible. It’s the same reason I want API providers to publish their versioning and deprecation policies, not just their versions. “Stable” in a folder name told you nothing. Beta, with a defined change process, a changelog and named maintainers, tells you how much to invest and what to watch.
It’s also an honest label for where adoption is. A week ago I counted four companies serving skills over MCP the way the spec says, out of 1,450 public MCP endpoints that answered. Beta is where an extension should be when that’s the number. It’s the stage where real usage shapes the final design.
So if you’re thinking about serving skills from your MCP server, Beta is an invitation, not a warning. The working group wants real implementations now, while the design can still learn from them. The Skills extension docs are the place to start.
https://apievangelist.com/2026/10/29/skills-over-mcp-is-now-officially-beta/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/skills-over-mcp-is-now-officially-beta.png
#rss #feeds #linksharing #qwibbit

2026-10-29 19:24:33 GMT

Automate Branch Cleanup And Push Notifications With GitLab
If you manage a software team, you have seen the repository that nobody tidies: hundreds of old branches, release branches someone forgot to protect, and a chat channel that never hears about a push until somebody complains. Those are housekeeping jobs, and housekeeping is exactly what software is good at. GitLab exposes all of it through an API, so a script, your internal tools, or an AI assistant can create, protect and clean up branches and wire notifications to your other systems.
What GitLab does
GitLab is a DevOps platform for building, securing and managing applications, made by GitLab Inc., an open-core company and one of the best known all-remote employers. It holds your code in Git repositories and adds issues, merge requests (a proposed change waiting for review), pipelines that build and test every change, and the runners that execute them. More on the GitLab website.
What you can get done
Create, protect and clean up branches
Software Construction Management is the day-to-day work on the code itself. A branch is a separate line of work in a repository; protecting one controls who can push to it.
GET /api/v4/projects/{id}/repository/branches lists all the branches in a project.
POST /api/v4/projects/{id}/repository/branches creates a new branch from main or a specific commit.
GET /api/v4/projects/{id}/repository/branches/{branch} shows one branch and its latest commit.
DELETE /api/v4/projects/{id}/repository/branches/{branch} deletes one named branch.
DELETE /api/v4/projects/{id}/repository/merged_branches deletes every branch that has already been merged.
Tell your other systems when something happens
Webhook & Event Subscription Management sets up webhooks, which are messages GitLab sends to a web address of yours whenever an event like a push happens.
GET /projects/{id}/hooks lists the webhooks configured on a project.
POST /projects/{id}/hooks adds a webhook, so your server hears about every push.
GET /projects/{id}/hooks/{hook_id} shows which events one webhook is subscribed to.
PUT /projects/{id}/hooks/{hook_id} changes where a webhook delivers.
DELETE /projects/{id}/hooks/{hook_id} stops a webhook altogether.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 24 for GitLab, including:
Clean Up a Merged Branch verifies a branch was merged, then unprotects and deletes it.
Create and Protect a Release Branch cuts a branch and immediately applies push and merge protection.
Create a Feature Branch from the Default Branch finds the tip of the default branch and starts new work from it.
Approve a Pending Project Access Request lists who has asked to join a project and approves the first one waiting.
Add and Preview a Project Badge previews a status badge, adds it to a project and confirms it.
Ask for it in plain language
Our conversational overlay for GitLab maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“How do I clean up every branch that has already been merged in a GitLab project?”
“How do I create a new branch from main or a specific commit?”
“How do I send a notification to my server whenever someone pushes to a project?”
“Which webhooks are configured on my GitLab project?”
“How do I delete one named branch from a project repository?”
You can see one in the GitLab Admin phrasing overlay.
Getting started
GitLab has a free tier with self-serve signup, and you call its hosted service. Read the REST authentication guide first; if you are building an app for other GitLab users, GitLab can act as an OAuth provider. There is also a GraphQL API and the Issues API reference. On APIs.io, see the GitLab profile, the Merge Requests API, the Pipelines API and the Issues API. Start with merged-branch cleanup on your busiest project; it is the safest win.
https://apievangelist.com/2026/10/29/automate-branch-cleanup-and-push-notifications-with-gitlab/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/automate-branch-cleanup-and-push-notifications-with-gitlab.png
#branch #gitlab #push #get #api #webhook #defaultbranch #create #software #merged
#rss #feeds #linksharing #qwibbit

2026-10-29 18:44:55 GMT

Manage Event Contacts, Discount Codes And Campaign Email With Cvent Event Cloud
If you run conferences, trade shows or customer events, most of the work happens between the events: keeping the contact list clean, setting up early-bird and partner discount codes, sending the invitations, and getting hotel and venue proposals in. Doing that by hand in a planner’s screen works for one event a year. It does not work for twenty. Cvent Event Cloud can do all of it through an API, which means your own software, your CRM, or an AI assistant acting on your behalf can do the clicking for you.
What Cvent Event Cloud does
Cvent Event Cloud is the event management product line of the Cvent Platform. It covers the whole event lifecycle: creating the event, registration, marketing, agenda and session management, mobile event apps, onsite check-in, virtual and hybrid delivery through the Attendee Hub, surveys and analytics. It also handles user provisioning through SCIM (a standard way for your identity system to create and remove user accounts), plus webhooks that notify your systems when something changes. More on the Cvent website.
What you can get done
Keep your event contacts organized
Customer Data Management is the address book behind every invitation. Groups work like distribution lists, so you can keep VIPs, speakers and sponsors apart.
POST /contact-groups creates a new contact group.
GET /contact-groups lists the groups in your address book.
PUT /contact-groups/{id} renames a group or changes its description.
GET /contact-groups/{id}/contacts lists which contacts belong to a group.
Set up discount codes for registration
Discount & Promotion Management lets you create promo codes and decide which sessions or admission items they apply to, without opening the event setup screens.
GET /events/{id}/discounts lists the discount codes on an event.
POST /events/{id}/discounts creates a new discount code.
PUT /events/{id}/discounts/{discountId} changes an existing discount’s settings.
PUT /events/{id}/discounts/{discountId}/agenda-items/{agendaItemId} makes a discount apply to a specific session or admission item.
Send campaign email and check it went out
Digital Marketing Management covers Cvent’s eMarketing, the invitations and reminders that drive registration.
GET /campaigns lists your eMarketing campaigns.
GET /emarketing/campaigns/{campaignId}/email-templates lists the email templates in a campaign.
POST /emarketing/emails sends a campaign email to recipients.
GET /emarketing/emails/{emailRequestId}/status checks whether a send went out.
Source hotels and venues
Sourcing Management reaches into Cvent’s RFP tools, where you ask venues and hotels to bid on your business.
GET /rfps/{rfpId}/suppliers lists the venues or suppliers that received an RFP.
GET /travel-programs lists your corporate travel programs.
GET /travel-proposals lists the hotel proposals that have come back.
Provision staff accounts from your identity system
Tenant Identity Federation is how IT keeps Cvent user accounts in step with the rest of the company.
GET /scim/v2/Groups lists Cvent user roles exposed as SCIM groups.
GET /scim/v2/ServiceProviderConfig shows which SCIM features the service supports.
Ask for it in plain language
Our conversational overlay for Cvent Event Cloud maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“Can I create a new discount code for an event?”
“Which sessions or admission items have a discount attached?”
“Did my eMarketing email send go out?”
“Which hotel proposals have come back for my travel RFPs?”
“Which contacts belong to a given contact group?”
You can see one in the Cvent Event Cloud Attendee Insights phrasing overlay.
Getting started
Cvent lists self-serve signup, and it is a hosted service you call. Access uses OAuth 2.0, the standard way to grant an application permission without sharing a password. Start with the REST API overview. On APIs.io, see the Cvent Event Cloud profile, the Cvent Platform REST API, the Events API and the Attendees API. Pick the chore you repeat most for every event, discount codes or contact groups, and automate that one first.
https://apievangelist.com/2026/10/29/manage-event-contacts-discount-codes-and-campaign-email-with-cvent-event-cloud/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/manage-event-contacts-discount-codes-and-campaign-email-with-cvent-event-cloud.png
#eventcloud #cventevent #get #discountcodes #eventcontacts #campaignemail #cventplatform #post #emarketing #attendeehub
#rss #feeds #linksharing #qwibbit

2026-10-29 18:04:12 GMT

Run Traffic Reports And Build Audience Segments With Adobe Analytics
Every Monday somebody on a marketing team opens the analytics tool, picks a date range, applies the same filters as last week, and exports the same report into a spreadsheet. Then somebody else asks for the same numbers for one customer group, and it starts again. If your company runs on Adobe Analytics, all of that can be done through an API, so a script, your data warehouse, or an AI assistant can pull the report and build the segment for you.
What Adobe Analytics does
Adobe Analytics provides real-time analytics and segmentation across marketing channels, helping organizations find high-value audiences and understand their customers. It collects the traffic and behaviour from your websites and apps into report suites (a report suite is one collection of data, usually one site or brand), and lets you slice it by dimensions such as page or campaign and metrics such as visits or revenue. More on the Adobe website.
What you can get done
Run reports without opening the tool
Analytics & BI Management is the reporting itself, including Data Warehouse, Adobe’s way of exporting large raw reports on a schedule.
POST /reports runs a report, such as page views by page for last month, with segment and date filters.
POST /{globalCompanyId}/data_warehouse/scheduled schedules a Data Warehouse export to run and be delivered automatically.
GET /{globalCompanyId}/data_warehouse/scheduled finds the scheduled requests you already have.
PUT /{globalCompanyId}/data_warehouse/scheduled/{UUID} changes when a scheduled request runs, or cancels it.
GET /{globalCompanyId}/data_warehouse/report/{UUID} checks the details and delivery status of one report.
Define the audiences you care about
Customer Segmentation Management manages segments, the saved definitions of a group of visitors, like “returning mobile buyers”.
GET /segments lists the segments in your company.
POST /segments creates a segment of visitors who match certain criteria.
GET /segments/{segmentId} shows the definition of one segment.
PUT /segments/{segmentId} updates an existing segment.
DELETE /segments/{segmentId} permanently removes a segment.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 12 for Adobe Analytics, including:
Create a Segment and Run a Segmented Report inspects a report suite’s dimensions, creates a segment, then runs a report filtered by it.
Create a Calculated Metric and Run a Report builds a new metric from existing ones and reports on it.
Annotate a Date Range and Run a Report marks a period, such as a launch week, and reports over it.
Clone a Segment copies an existing segment under a new name.
Estimate and Run a Data Repair Job sizes a fix to collected data, submits it and checks its status.
Ask for it in plain language
Our conversational overlay for Adobe Analytics maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“How do I pull page views by page for last month from a report suite?”
“How do I schedule a Data Warehouse export to run and be delivered automatically?”
“How do I create a segment of visitors who match certain criteria?”
“What segments exist in my Adobe Analytics company?”
“Can I change when a scheduled Data Warehouse request runs?”
You can see one in the Adobe Analytics Account phrasing overlay.
Getting started
Adobe Analytics is paid. Start with the Livestream guide if you want hits in real time. The 1.4 APIs are deprecated, so build new work on the current version. On APIs.io, see the Adobe Analytics profile, the Reports API, the Report Suites API and the Livestream API. Take the one report you rebuild every week and make it the first thing you automate.
https://apievangelist.com/2026/10/29/run-traffic-reports-and-build-audience-segments-with-adobe-analytics/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/run-traffic-reports-and-build-audience-segments-with-adobe-analytics.png
#adobeanalytics #data #run #segment #datawarehouse #get #build #post #globalcompanyid #daterange
#rss #feeds #linksharing #qwibbit

2026-10-28 23:33:21 GMT

Two Hundred Nine API Companies And Seven Hundred Seventy-Five Enterprises Hire In Different Worlds
For the last three weeks I have been comparing two groups of companies inside the Q3 2026 Insights pull, and every time the comparison has been the most interesting part. So this week it is the whole story.
The pull read 343,299 job postings from 984 companies. 775 are in the Fortune 1000. 209 are API providers from the APIs.io catalog, the companies whose product is, at least in part, an API. Every number below is a count of companies whose postings name the term at least once, shown as a share of each group.
One warning before the tables, and it applies to all of them: 209 companies is a much smaller sample than 775. A few companies on the provider side move a percentage a long way. Read every gap here as a direction, not a measurement.
What the API companies name far more often
Fortune 1000
API providers
ratio
Zapier
2.3%
18.7%
8.0x
ClickHouse
3.4%
12.4%
3.7x
Google Workspace
12.0%
34.9%
2.9x
Vercel
2.7%
7.7%
2.8x
SOC 2
15.7%
36.8%
2.3x
Kubernetes Operators
2.7%
6.2%
2.3x
Dagster
3.9%
8.1%
2.1x
Claude
33.3%
58.4%
1.75x
Pulumi
6.6%
10.5%
1.6x
Kubernetes
48.0%
71.8%
1.5x
Zapier is the headline: named by nearly one in five API providers and about one in forty enterprises. That makes sense once you remember who these companies are. For an API company, Zapier is often a distribution channel, the place a lot of their customers meet the API without writing code, so they hire people who know how to build and run that integration.
The rest of the list reads like a modern engineering organization. Analytics on ClickHouse, the front end on Vercel, pipelines on Dagster, infrastructure as code on Pulumi, workloads on Kubernetes and the operators that run on it. Google Workspace instead of the Microsoft office stack. And SOC 2, the attestation an API company has to hand every enterprise customer before the contract gets signed.
What the enterprises name far more often
Fortune 1000
API providers
ratio
Microsoft Outlook
74.1%
17.2%
0.23x
Microsoft Excel
68.6%
20.6%
0.30x
Microsoft Word
45.3%
7.7%
0.17x
Azure DevOps
38.6%
10.0%
0.26x
Process Flow Diagrams
35.5%
9.1%
0.26x
Microsoft Project
34.8%
9.1%
0.26x
Microsoft Teams
27.6%
8.1%
0.29x
Microsoft Power Automate
27.0%
5.7%
0.21x
Power Query
24.8%
6.2%
0.25x
Adobe Illustrator
19.1%
4.8%
0.25x
Three out of four Fortune 1000 companies name Outlook in a posting. Almost half name Word. That is not engineering vocabulary, and that is the point. An enterprise posts for every kind of role, and most of those roles live inside the Microsoft office stack. Even the automation shows up in the enterprise as Power Automate, not as Zapier, and the delivery pipeline as Azure DevOps.
It also tells you something about whose postings you are reading. The API provider side is mostly engineers, product people, and go-to-market for a technical product. The enterprise side is a whole workforce, with a technology organization somewhere inside it.
Systems of record
Fortune 1000
API providers
Salesforce
60.9%
70.3%
Workday
61.4%
28.2%
SAP
57.0%
20.1%
ServiceNow
43.2%
19.1%
Snowflake
38.5%
42.1%
Databricks
34.2%
29.7%
MuleSoft
13.5%
7.2%
Apigee
7.7%
1.0%
Salesforce is the one big system both groups share, and the API providers actually name it more. After that the enterprise stack pulls away: Workday, SAP, and ServiceNow at two to three times the provider rate. The data platforms, Snowflake and Databricks, are close to even. The enterprise integration and API management layer — MuleSoft, Apigee — is mostly an enterprise hiring term. Apigee is named by 7.7% of the Fortune 1000 and 1.0% of the API providers.
Which cloud a company leans on
Here is a different cut. For each company, which of the three big clouds do its postings name most often?
lead cloud
all 984
API providers
Fortune 1000
AWS
313
99
214
Azure
223
19
204
Google Cloud
89
27
62
tie
116
31
85
none
243
33
210
Among the API providers, AWS leads at 99 of 209 companies, about 47%, and Azure leads at only 19, about 9%. In the Fortune 1000 AWS and Azure are nearly level, 214 to 204, about 28% and 26% of the group.
The none row is a real reading, not missing data. It is 243 companies whose postings do not name any of the three clouds at all, and 210 of them are in the Fortune 1000 — about 27% of that group, against about 16% of the API providers. Plenty of large companies run on a cloud they never mention in a posting.
What I think it means
API Evangelist has always said that an API is a bridge between two organizations, and this is a picture of the two ends of that bridge. On one side, a company that runs on Kubernetes and Terraform, sells through Zapier, proves itself with SOC 2, and leans on AWS. On the other, a company that runs on Outlook, Excel, Workday, SAP, and ServiceNow, automates with Power Automate, and manages its APIs with MuleSoft or Apigee.
When an API provider writes its docs, its onboarding, and now its MCP server, it tends to write for the first kind of company, because that is who it hires and who it is. Most of the money is on the other side. The people who will wire your API into a Fortune 1000 company are going to arrive through their own gateway, their own identity provider, their own automation tools, and their own security review. If your developer experience only makes sense from inside the first world, you are making the second world translate.
How to read these numbers
This is hiring intent, not production use. A company that names Outlook in a posting is telling you what its people work in, not what its engineers build on.
Q3 2026 is the first point in the series. None of these gaps is widening or closing yet. The Q4 read comes on November 20.
Small side, big swings. Every provider percentage is out of 209 companies. Treat the ratios as which way things lean.
Only verified terms. The ratio tables only include terms that passed our verification pass and are named by at least ten companies on each side.
The full Insights data, with both groups and every term, is available through the APIs.io API and MCP server.
Two worlds, one bridge. I will be watching both ends of it when the Q4 numbers come in on November 20.
https://apievangelist.com/2026/10/28/two-hundred-nine-api-companies-and-seven-hundred-seventy-five-enterprises-hire-in-different-worlds/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/two-hundred-nine-api-companies-and-seven-hundred-seventy-five-enterprises-hire-in-different-worlds.png
#api #apicompanies #microsoft #hire #fortune #powerautomate #every #two #googleworkspace #kubernetes
#rss #feeds #linksharing #qwibbit

2026-10-28 22:57:03 GMT

Advertising: The Shape Of The Answer
Last week I wrote about DeepInfer and the shape of the answer, and how batch-invariant inference, deterministic sampling and schema-constrained output make valid JSON table stakes and push the real work onto agreeing on the shape. Advertising is the industry I wanted to look at next, because it agreed on its shape more than fifteen years ago and then runs that shape at a volume nobody else does.
The answer this industry needs
There are two answers I keep seeing people try to get out of a model in advertising.
The first is turning a campaign brief into something a buying system will accept. A planner writes “CTV, US only, 30 second video, no gambling adjacency, private deal with this publisher.” What a machine needs is a valid bid request or a valid deal: the impression, the video constraints, the blocked categories, the deal id and floor, in the fields an exchange or a DSP will actually parse.
The second is classifying content into the IAB content taxonomy. Every page, app and stream an ad might land on needs a category, and that category drives targeting and brand safety. The answer needs to be a code from a published list, not a description of what the page seems to be about.
Both are shape problems. Neither one is useful as prose.
The shape is already written down
The IAB Tech Lab governs the shapes. OpenRTB is the real-time bidding protocol, and the current 2.6 specification on GitHub is still being revised, with its most recent release tagged 2.6-202606. It defines a BidRequest made of Imp objects, each carrying a Banner, Video, Audio or Native object, a Pmp holding Deal objects, plus Site or App, Device, User, Regs and a SupplyChain. The answer comes back as a BidResponse holding SeatBid objects, each holding a Bid. Even the clock is in the contract: tmax is the maximum time in milliseconds the exchange allows for bids to arrive.
AdCOM holds the shared lists that OpenRTB points at. The cattax field in OpenRTB 2.6 says which category taxonomy is in use and refers to the AdCOM list of category taxonomies for its values. That is the hook for the second answer. The IAB Tech Lab Content Taxonomy is at version 3.1, released December 2024, and the Tech Lab says plainly that version 1.0 is deprecated and should not be used. It has also published a taxonomy mapper for moving from 2.x to 3.0. VAST is the video ad serving template, the XML a player reads to play a video ad, now at 4.3.
So the brief-to-deal problem has a schema, and the classification problem has a controlled vocabulary with versioned ids. That is exactly what a constrained decoder wants: a JSON schema for the bid request, and an enum or grammar built from the taxonomy ids.
What the catalog holds
The APIs.io standards page lists two advertising standards. OpenRTB is carried as a tag by 14 providers in the catalog, led by BidMachine at 56.4, Magnite at 51.2, InMobi at 48.3 and Opera at 47.1, down through TripleLift, OpenX, Sharethrough and PubMatic. VAST shows no provider tagged yet. AdCOM and the content taxonomy have no entry on the list at all. The tag is a provider’s own statement, and APIs.io says on the page that it has not verified the implementation.
The market I track for this is Adtech and Privacy, a 25 member cohort that mixes buying and selling platforms with consent management. The leaders on the Kin Score are Didomi at 80.0, Outbrain at 74.9, Google Ads at 71.9, OneTrust at 71.7 and Taboola at 71.0. On agent readiness the order changes: Scope3 leads at 65.8, then OneTrust at 55.9 and Singular at 50.0. Didomi, the top composite score, is 30.4 on agent readiness. At the bottom, PubMatic is 27.2, Integral Ad Science 28.1, DoubleVerify 29.1 and Microsoft Advertising 25.6, with Microsoft Advertising at 3.1 on agent readiness.
The gap I care about is between the people who run the auction and the people with good contracts. Only five of the 14 OpenRTB providers sit in this cohort, Magnite, TripleLift, OpenX, Sharethrough and PubMatic, and their composite scores run from 27.2 to 51.3. The exemplar scores in this market belong to consent platforms and content recommendation, not to exchanges.
The artifacts follow the same line. Of the 25 cohort repos, 6 hold JSON Schema, 3 hold vocabularies, 3 hold examples, 2 hold JSON Structure, 7 hold AsyncAPI and 1 holds Arazzo. Didomi is the only one with all of them, including nine Arazzo workflows such as recording a consent event and issuing a consent token. MediaMath has 308 JSON Schema files covering campaign objects like advertisers, agencies and creatives. Some of these were derived by API Evangelist from the providers’ own OpenAPI rather than published by the provider, so read them as our work on top of theirs.
What I could not find is anyone in the cohort publishing OpenRTB itself as a machine-readable contract. Magnite describes its platform as having REST and OpenRTB APIs, and its OpenAPI references the OpenRTB seatbid object by name. Our TripleLift profile records that buyers POST OpenRTB bid requests to a single endpoint with no OpenAPI document, and that the supported OpenRTB subset is documented as prose tables, with no JSON Schema for it.
What determinism changes here
Advertising is where batch-invariance stops being an academic property. An exchange answers bid requests by the billions, in batches, inside a tmax budget. If a model sits anywhere in that path, building a request from a brief, scoring brand safety, or tagging content with a taxonomy id, the batch it lands in can’t be allowed to change the answer. Without batch-invariance, the same page could get a different category depending on what else was being classified alongside it, and a buyer’s blocked categories would be enforced unevenly.
Determinism also matters after the auction. Advertisers, agencies and verification vendors reconcile delivery against what was promised. When a buyer asks why an impression was classified as news and not gambling, “the model said so that time” isn’t an answer. The same input producing the same taxonomy id every time is something you can audit. The Regs object carries privacy signals into every request, and the consent platforms in this cohort exist because regulators expect those signals to be handled the same way every time.
Constrained output closes the last gap. Constrain the decoder to the OpenRTB 2.6 schema and a brief can only become a BidRequest an exchange will parse. Constrain it to the Content Taxonomy 3.1 ids and it can only emit categories that exist. It can’t emit a deprecated 1.0 code.
Where it falls short
The shapes are written down, but mostly as Markdown and prose on GitHub, not as the JSON Schema a constrained decoder takes as input. The exchanges that carry OpenRTB are thin on public contracts, and the ones I can see document their subset of the spec in tables. VAST has no provider tagged on APIs.io. AdCOM and the content taxonomy aren’t on the standards list. The market’s best published artifacts are about consent and campaign management, not the bid request itself. Everyone implements a subset of OpenRTB and describes the subset in their own words, which is the decision model problem again, inside a standard.
Advertising did the hard part years ago when it agreed on the bid request. What it hasn’t done is publish that agreement, and each exchange’s subset of it, in a form a machine can hold a model to. The providers who publish their OpenRTB subset as a schema, and their taxonomy as a vocabulary, are the ones whose shapes will get used.
https://apievangelist.com/2026/10/28/advertising-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/advertising-the-shape-of-the-answer.png
#shape #answer #techlab #iabtech #advertising #taxonomy #deal #openrtb #bid #contenttaxonomy
#rss #feeds #linksharing #qwibbit

2026-10-28 22:46:41 GMT

Trigger Builds And Retry Failed Jobs Automatically With Buildkite
If your business ships software, every change your team makes has to be built, tested and released, and when something breaks, someone has to find out why and run it again. That loop is called continuous integration and delivery, or CI/CD. Buildkite runs it, and it exposes the whole thing through an API, so a chat bot, a release script, or an AI coding assistant can start builds, read the logs and retry failures without anyone logging in to a dashboard.
What Buildkite does
Buildkite is a hybrid CI/CD platform. Hybrid means Buildkite runs the control panel, while the agents that actually do the work run on machines you control, or on machines Buildkite hosts for you. It has three products, Pipelines, Test Engine and Package Registries, and offers a REST API, a GraphQL API, an Agent API, webhooks and an official MCP server that makes those APIs available to AI coding agents. More on the Buildkite website.
What you can get done
Run and manage builds
Buildkite’s work sits under one capability, Continuous Integration Management. A pipeline is the set of steps your code goes through; a build is one run of that pipeline; a job is one step inside a build.
GET /organizations/{org}/pipelines lists your organization’s pipelines.
POST /organizations/{org}/pipelines/{pipeline}/builds starts a new build, without anyone pushing code.
GET /organizations/{org}/pipelines/{pipeline}/builds shows the recent builds of a pipeline.
GET /organizations/{org}/pipelines/{pipeline}/builds/{number} tells you whether one build passed.
PUT /organizations/{org}/pipelines/{pipeline}/builds/{number}/cancel stops a build that is still running.
Recover when something fails
The same capability handles the part that eats the most time: working out what broke and running it again.
GET /organizations/{org}/pipelines/{pipeline}/builds/{number}/jobs/{job}/log fetches the log output of a job.
PUT /organizations/{org}/pipelines/{pipeline}/builds/{number}/jobs/{job}/retry retries a single job.
PUT /organizations/{org}/pipelines/{pipeline}/builds/{number}/rebuild re-runs an entire build with the same settings.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 9 for Buildkite, including:
Build Failure Triage inspects a finished build and pulls its annotations and artifacts.
Retry Failed Job finds the failed job, retries it and watches the build to the end.
Fetch Job Log reads a build, picks a finished job and fetches its log.
Provision Pipeline And First Build creates a pipeline and triggers its first build.
Stop Disconnected Agent finds an agent that has dropped off and stops it.
Ask for it in plain language
Our conversational overlay for Buildkite maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“How do I trigger a new build through the Buildkite API?”
“How do I see the recent builds of one of my pipelines?”
“What’s the state of a specific build number?”
“How do I cancel a build that’s still running?”
You can see one in the Agents phrasing overlay.
Getting started
Buildkite is paid, with self-serve signup, and it is a hosted service you call. Start with managing API tokens, then the GraphQL API, the GraphQL cookbook and the Agent API. On APIs.io, see the Buildkite profile, the MCP Server, the GraphQL API and the Agents API. If your team retries the same flaky job by hand every week, automate that retry first.
https://apievangelist.com/2026/10/28/trigger-builds-and-retry-failed-jobs-automatically-with-buildkite/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/trigger-builds-and-retry-failed-jobs-automatically-with-buildkite.png
#retryfailed #buildkite #builds #pipeline #job #get #api #run #agent #log
#rss #feeds #linksharing #qwibbit

2026-10-28 22:10:02 GMT

Can Your MCP Server Finish The Job?
When I wrote that MCP is last-mile plumbing, the best response I got wasn’t a comment. It was a repost, with one example that turned my analogy into a test. An email MCP connector will happily draft a message for you. It will not attach the file, and it will not send it. To finish the job, you drop out of the agent and back into the app, or into the real API.
That is the test. Run the workflow end to end through the MCP server alone. If you have to leave it to do the last step, the server is a demo surface, not infrastructure.
The last step is the job
Most work an agent does for someone ends in a verb that changes something. Send the email. Submit the order. Pay the invoice. Publish the post. Merge the change. Book the room. Everything before that verb is preparation: searching, reading, drafting, composing. Preparation is useful, and it is also the cheap, safe part. It is the part a provider can ship without having to think about permissions, confirmation, idempotency or what happens when something goes wrong.
So it makes sense that a lot of MCP servers stop there. A read-only server is easy to publish and hard to get in trouble with. But an agent that can draft and can’t send is not doing the job. It is handing the job back to a person with extra steps.
What the catalog shows
I looked at the tool lists of the 1,350 live, hosted MCP servers on APIs.io that publish one, 18,355 tools in all, and sorted each tool by the verbs in its name.
438 servers, about a third, have no tool whose name suggests it changes anything. Every tool gets, lists, searches, reads, fetches or describes.
912 have at least one tool that writes, creates, updates, deletes, uploads or otherwise changes state.
648, just under half, have at least one tool that completes something, a send, submit, pay, publish, book, order, sign, deploy, merge or similar.
This is a name-based reading, not a run of every workflow, so treat it as a direction. Names lie in both directions. A get_ tool can have side effects, and a server with a send_ tool can still be missing the one step your workflow ends on. The email example passes a name check and fails the real one. That is why the test has to be the workflow, not the tool list.
A read-only server is a choice, so say so
I’m not arguing every server should write. There are good reasons to ship read-only first, and plenty of servers whose whole job is retrieval: documentation, search, reference data, analytics. Those pass the test, because reading is the job.
The problem is a server that covers the start of a workflow and leaves the end out without saying so. The agent finds the draft tool, does the work, and then can’t finish. The person it’s working for finds out last.
If your server stops short of the final action, say it in the server instructions and in the tool descriptions: this server drafts and does not send, and here is where sending happens. That’s honest, and it lets the agent tell the person up front instead of at the end. Better still, mark the tools that do act with the annotations MCP already has, readOnlyHint, destructiveHint and idempotentHint, so a client knows what to confirm with a human before it runs.
Test the workflow, not the surface
Here is the check I’d add to any MCP server’s release process, and the one I’m working toward in Agent Readiness:
Write down the three to five jobs people actually use your product for, ending in the verb that finishes each one.
Run each job through your MCP server alone, with an agent, from the first step to that final verb.
Where the server can’t finish, either add the terminal action, with confirmation and idempotency, or document that it stops and where the rest happens.
An API is how a business does something. An MCP server built on top of it should be able to do the same thing, or tell you plainly that it can’t. If it can draft but not send, it is a preview of your product, not your product.
https://apievangelist.com/2026/10/28/can-your-mcp-server-finish-the-job/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/can-your-mcp-server-finish-the-job.png
#mcpserver #job #send #publish
#rss #feeds #linksharing #qwibbit

2026-10-28 21:31:48 GMT

Run A Managed Graph Database And Predict Connections With Amazon Neptune
Some business questions are really questions about connections. Which customers are linked to the same fraudulent card? Which products are bought together? Who knows whom in your network? A spreadsheet or an ordinary database struggles with these, because the answer lives in the relationships, not the rows. Amazon Neptune is a database built for exactly that, and you can set it up, load it and run it through an API, so your own software, your operations scripts, or an AI assistant can do the work instead of someone clicking through the AWS console.
What Amazon Neptune does
Amazon describes Neptune as a fully managed graph database service for applications that work with highly connected datasets. A graph database stores things (people, accounts, products) and the links between them. Neptune supports the two common ways of modelling that, property graph and RDF, and the query languages that go with them: Gremlin, SPARQL and openCypher. Managed means Amazon runs the servers, backups and patching for you. More on the Amazon Neptune page.
What you can get done
Stand up and look after the database
IT Infrastructure Management is the plumbing: creating a database cluster (a group of servers working as one database), changing it, pausing it when you are not using it, and removing it.
POST / with the create action provisions a new Neptune database cluster.
POST /?Action=ModifyDBCluster changes a cluster’s settings, such as how long backups are kept.
POST /?Action=StopDBCluster stops a running cluster, and POST /?Action=StartDBCluster starts it again.
POST /?Action=CreateDBInstance adds another server to a cluster.
POST /?Action=DeleteDBCluster deletes a cluster you no longer need.
Train models that learn from your connections
Artificial Intelligence Management is Neptune ML: using machine learning on your graph to predict things, such as a likely link between two accounts, that are not yet recorded.
POST /ml/dataprocessing prepares your graph data, stored in S3, for training.
GET /ml/dataprocessing/{jobId} tells you whether that preparation is finished.
POST /ml/modeltraining starts training a model.
POST /ml/endpoints deploys the trained model so you can ask it for predictions.
GET /ml/endpoints lists the prediction endpoints you have running.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 25 for Neptune, including:
Bulk Loader Start and Poll loads data from S3 and waits until the load completes.
Analytics Create Graph from Import Task creates a Neptune Analytics graph filled from S3.
Analytics Snapshot and Restore snapshots a graph and restores it into a new one.
Analytics Reset Graph empties a graph and waits until it is ready again.
Gremlin Add and Count Vertices adds records to a graph and counts them back.
Ask for it in plain language
Our conversational overlay for Neptune maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“What Neptune DB clusters do I have provisioned?”
“How do I provision a new Amazon Neptune database cluster?”
“Can I rename an existing Neptune cluster or change its backup retention?”
“How do I prepare graph data in S3 for Neptune ML training?”
“Is my ML data processing job done?”
You can see one in the DB Clusters phrasing overlay.
Getting started
Neptune is paid, with pricing on the AWS site, and it is a hosted service you call. The AWS guides cover querying with Gremlin, querying with openCypher and what Neptune Analytics is. On APIs.io, see the Amazon Neptune profile, the DB Clusters API, the Data Processing API and the Graph Snapshots API. Write down the one relationship question your business keeps asking, and test whether a graph answers it before you build anything bigger.
https://apievangelist.com/2026/10/28/run-a-managed-graph-database-and-predict-connections-with-amazon-neptune/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/run-a-managed-graph-database-and-predict-connections-with-amazon-neptune.png
#amazonneptune #graph #post #database #managedgraph #action #predict #analytics #get #run
#rss #feeds #linksharing #qwibbit

2026-10-28 20:51:58 GMT

The MCP Maintenance Bill Depends On How You Built It
One of the sharpest responses to MCP is last-mile plumbing took my own argument to the CFO. If the API is the water main and the MCP server is the flexible supply line under the sink, then teams are now paying for two surfaces, forever. Someone has to budget for maintaining the MCP server alongside the API it sits on.
That’s right, and I want to start by granting it. I told that commenter I’d help make the budget argument, so here it is. The answer is that the bill depends almost entirely on how the server was built.
Two ways to build the same server
A derived server is generated from the contracts you already have. Your OpenAPI says what the operations are. A small set of rules, which I’d argue every team should write down, says which of those operations become tools, what they’re named, how they’re described, which ones are read-only and which ones need confirmation. A build step turns the two into a tool list. When the API changes, the contract changes, the build runs, and the server changes with it.
A hand-written server is code someone wrote against whatever was lying around: the API, the SDK, the database, a few internal endpoints, sometimes the website. It has its own names, its own descriptions, its own error handling and its own idea of what each operation does. When the API changes, someone has to notice, and someone has to go change the server too.
The first is a build artifact. The second is a second product.
What each one actually costs
A derived server’s ongoing cost is close to the cost of the build step and the rules file. You paid for the contract already. You were going to version it, review it and test it anyway. The MCP server inherits all of that work instead of duplicating it. The real maintenance is in the rules, deciding which operations an agent should be allowed to touch and how they should read, and that’s governance work that pays off everywhere the contract is used.
A hand-written server’s cost compounds. Every API release is a chance for the two to drift. Every bug gets fixed twice, or once and in the wrong place. Every new name, description and error message is written by hand, and the next person writes theirs differently. Nobody budgeted for that, because on day one it looked like a few days of work.
The catalog shows both failure modes. When I read 103,737 MCP tool names across 4,439 servers, 2,787 tools across 315 servers were named after an HTTP method. That is an OpenAPI turned into tools with no rules in between, derived without the governance. And 228 servers mixed naming styles inside a single tool list, which is what hand-writing looks like when more than one person does it. Even our own two servers, built by the same practice within months of each other, had drifted from each other before I wrote the conventions down.
The budget argument
So the line to put in front of a budget owner is not “MCP costs extra.” It’s this: a hand-written MCP server costs extra, every release, forever. A derived MCP server is a line item you already paid for when you invested in your API contracts.
That changes where the money should go:
Fund the contracts. Complete OpenAPI, with examples and good descriptions. It’s the source for the API docs, the SDKs, the tests and now the MCP server.
Fund the rules. One short style guide for how operations become tools: naming, descriptions, annotations, what’s exposed and what isn’t. Write it once, enforce it in the build.
Don’t expose everything. Generating a tool for every endpoint is the cheap way to derive a server and the expensive way to run one. The rules should pick the handful of jobs an agent should be allowed to do.
Hand-write only the exceptions, and treat each one as code you’ll own for as long as the server lives.
Dual maintenance is real. But it isn’t a tax on MCP. It’s a tax on skipping the contract. If the mains are built properly, the supply line is the cheapest part of the plumbing to keep running.
https://apievangelist.com/2026/10/28/the-mcp-maintenance-bill-depends-on-how-you-built-it/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-mcp-maintenance-bill-depends-on-how-you-built-it.png
#rss #feeds #linksharing #qwibbit

2026-10-28 20:16:00 GMT

Australian Government Is Open But Not Yet Discoverable By Agents
Australian government publishes more than almost anyone, and an agent still cannot find most of it on its own.
This is the third in a short series ahead of The API Economy Roundtables at apidays Australia today. On Monday I ranked the most programmable sectors in Australia, and yesterday I looked at how regulation writes the API for banking and energy. Government was the second most programmable sector in the ranking, and the only one where every single publisher had something on offer. It is also the one with the clearest gap.
Thirteen publishers, zero dark
I profiled 13 Australian government API publishers: the ATO, ABS, Services Australia, the Australian Business Register, the Bureau of Meteorology, the Australian Digital Health Agency, CSIRO, Trove, data.gov.au, Transport for NSW open data, NSW open government, Public Transport Victoria and Translink Queensland.
12 of 13 have a developer portal. That is the highest rate of any sector, tech included.
7 of 13 publish their own contracts. Not contracts we generated from their docs — OpenAPI the agencies publish themselves.
None of them has nothing. Government is the only sector in the cohort with no company in the “nothing for an agent to read” column.
The contracts are real and substantial. The ATO publishes its digital service gateway APIs, from stapled super fund lookups to GST property settlement and the new global minimum tax returns. CSIRO publishes its Data Access Portal APIs. Transport for NSW publishes more than forty contracts across its open data hub. NSW open government publishes fuel prices, the pharmacy register and property data. Trove, ABS and PTV publish theirs too.
And not one of them is agent-ready
Here is the other column.
Signal
Government publishers
Developer portal
12 of 13
Own contract
7 of 13
MCP server
0
A2A agent card
0
OAuth protected resource metadata
0
llms.txt on their own domain
2
Australian government did the hard part. It published the contracts, stood up the portals, and documented the data. What it has not done is the thin layer on top that tells an agent where all of that is and how to use it. No MCP servers. No agent cards. No protected resource metadata telling an agent which authorization server guards an API. Two llms.txt files out of thirteen.
The front door problem
There is a second, more practical issue. Several of these publishers turn agents away at the door.
The ATO, data.gov.au and Public Transport Victoria answer an automated visitor with an anti-bot challenge. data.gov.au returned a 503.
The ABS serves a JavaScript-only shell that has to be rendered before there is anything to read.
Services Australia and the Australian Digital Health Agency did not answer our probes at all.
This matters more for government than for anyone else. Public data is published to be used, and increasingly it is going to be used by an agent acting for a citizen, a small business or a researcher. The ATO still publishes its contracts behind its challenge — and it even supports OAuth dynamic client registration, which is exactly the kind of machine-native onboarding agents need. But an agent that stops at the homepage never gets that far.
Why this is the easiest gap to close
Of all the gaps in the Australian data, this is the one I am most optimistic about. Government has already done the expensive work. Adding an MCP server in front of a published OpenAPI, an agent card that points at the portal, protected resource metadata on the APIs that already use OAuth, and an llms.txt that indexes the docs is a small amount of work compared to what already exists. It is also the kind of thing that can be standardised once and applied across every agency.
The timing lines up. The Commonwealth has stood up an Office of AI and promised AI standards legislation. Finance has been consulting on a whole-of-government verifiable credentials policy. Digital identity, credentials and AI policy are all moving at the same time. The API layer underneath is ready. Making it discoverable is the missing step.
That is the question I want to put to the room today, as part of the conversation on regulation, privacy and digital identity: if government is going to set the rules for how agents behave, should it also be the first sector to make itself properly discoverable by them?
If you are at apidays Australia, come find us at the roundtables. All thirteen government profiles are on APIs.io.
https://apievangelist.com/2026/10/28/australian-government-is-open-but-not-yet-discoverable-by-agents/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/australian-government-is-open-but-not-yet-discoverable-by-agents.png
#australiangovernment #nsw #servicesaustralia #data #api #transport #publictransport #healthagency #own #ato
#rss #feeds #linksharing #qwibbit

2026-10-28 19:38:52 GMT

Who Actually Gets To Define API Standards
Every API standard I’ve watched take shape was decided by somebody, and it was rarely the people who end up living with it. I’ve been thinking about this a lot since forking Spectral into OpenLint, because the first real question a fork has to answer is not technical. It is who gets a say.
As far as I can tell, there are four groups shaping API standards, and they do not have anything close to equal volume.
The market
Customers, the people who actually build and consume APIs, are the ones a standard is supposed to serve. They have the most at stake and the least organized voice. They show up as demand: a format everyone quietly adopts, a pattern that spreads because it works, a feature request repeated across a hundred issue trackers. Spectral rulesets became a de facto standard this way. Governments and banks started publishing their API design rules in a format nobody had ever specified, because it was what worked.
The market defines standards by adoption, after the fact. It rarely gets a seat while the thing is being written.
Vendors
Vendors have the seats. They build the tools, fund the foundations, staff the working groups and ship the implementations everyone else has to be compatible with. That’s not a bad thing. Most of the specifications I depend on exist because a company paid people to write them. But a vendor’s priorities are its roadmap, and a standard that depends on one vendor depends on that roadmap. I watched Swagger become OpenAPI. I’m watching Spectral’s format live inside one company’s CLI. The vendor is usually the first to define a standard and the last to want it pinned down.
VCs and their portfolios
This is the loudest group right now, and the least discussed. Investors don’t write specifications, but they decide which companies get the budget to show up, and their portfolios carry the biggest megaphone in the room. When a funded wave of companies all adopts the same protocol at the same time, it becomes a standard by sheer volume, whether or not anyone ever agreed on it. Much of what is being called a standard in the agent space this year looks like this to me. Momentum gets mistaken for consensus.
Academia
Then there’s the group with the deepest work and the quietest voice. Researchers have been working on machine-readable APIs for a long time. Hydra described hypermedia-driven web APIs on top of JSON-LD years before agents needed them. SLA4OAI extended OpenAPI to describe service-level agreements, plans and rate limits, exactly the things I now spend my days trying to get providers to publish. Most of the industry never read either.
And there’s another version of this group that I run into constantly: academics inside organizations, disguised as architects. People doing careful, rigorous standards thinking inside enterprises, whose work never leaves the building. A lot of what the public conversation is rediscovering already exists in somebody’s internal wiki.
Why this matters
When a standard is defined mostly by vendors and VCs, it tends to serve the people selling, not the people building. When it’s defined mostly by academia, it tends to be right and unused. When it’s defined only by the market, it’s useful but never written down, which is how a configuration file ends up as the API design rules of entire governments.
The work I want to do, and that I try to do with The Specification Layer, is to make the quiet groups louder. Read what actually merged, not just what was announced. Bring the research back into the room. Measure what the market actually adopted instead of what got the press release. And, with OpenLint, set the table so that the people who live with a standard have as much say as the people who sell it.
If you’re one of the quiet ones, a customer with an opinion, a researcher whose work got skipped, or an architect sitting on something good inside your company, the rooms are open. Most specification calls are public, recorded and looking for people who don’t have a product to sell. Show up.
https://apievangelist.com/2026/10/28/who-actually-gets-to-define-api-standards/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/who-actually-gets-to-define-api-standards.png
#apistandards #gets #spectral #everyapi
#rss #feeds #linksharing #qwibbit

2026-10-28 18:58:44 GMT

Connect To Your Customers Accounting, HR And CRM Systems With Merge
If you build software for other businesses, sooner or later every customer asks the same question: does it work with our accounting system, our HR system, our CRM? There are dozens of each, and building a connection to every one is a job that never ends. Merge offers one API that sits in front of many of those systems, so your product, or an AI assistant acting for you, can read and write invoices, candidates, payroll and deals the same way no matter which system your customer happens to use.
What Merge does
Merge describes itself as connective infrastructure for production AI. Its Unified API is one surface across HRIS (HR information systems), ATS (applicant tracking systems), accounting, CRM, ticketing, file storage, knowledge bases and chat. It also offers Agent Handler, which exposes pre-built enterprise connectors to AI agents, and Gateway, a unified API across several large language model providers. More on the Merge website.
What you can get done
Work with invoices in any accounting system
Financial Management lets your product see and create invoices in whatever accounting platform your customer has connected.
GET /accounting/v1/invoices lists invoices, such as the ones still unpaid.
POST /accounting/v1/invoices creates an invoice in the connected platform.
GET /accounting/v1/invoices/{id} shows the line items and totals of one invoice.
PATCH /accounting/v1/invoices/{id} changes an invoice that already exists.
Move candidates through hiring
Talent Acquisition Management connects to applicant tracking systems, so a job board or assessment tool can hand candidates over without copy and paste.
GET /ats/v1/candidates lists candidates, and finds one by email.
POST /ats/v1/candidates adds a new candidate.
GET /ats/v1/candidates/{id} shows what the system has on file for one person.
PATCH /ats/v1/candidates/{id} updates a candidate’s details.
Read payroll results
HR Operations Management reaches into HR and payroll systems, useful for benefits, lending or finance products that need to see pay.
GET /hris/v1/payroll-runs lists the payroll runs a company has processed.
GET /hris/v1/payroll-runs/{id} shows the dates and status of one run.
GET /hris/v1/employee-payroll-runs lists individual employees’ pay results.
GET /hris/v1/employee-payroll-runs/{id} reads one employee’s paystub-level record.
Keep deals in sync with the CRM
Opportunity & Pipeline Management works with deals in your customer’s CRM.
GET /crm/v1/opportunities pulls open deals.
POST /crm/v1/opportunities adds a new deal.
GET /crm/v1/opportunities/{id} looks up one deal.
PATCH /crm/v1/opportunities/{id} moves a deal to a new stage or changes its amount.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 19 for Merge, including:
Accounting Link an Account connects a customer’s accounting platform to your product.
Accounting Bill a Customer creates a customer contact, raises an invoice and confirms it.
Bulk Create Expenses and Poll the Batch submits a batch of expenses and waits for it to finish.
ATS Add a Candidate and Application creates a candidate and applies them to an open job.
ATS Advance an Application Stage moves an application to the next interview stage.
Ask for it in plain language
Our conversational overlay for Merge maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“Which invoices are still unpaid in my customer’s accounting system?”
“How do I add a new candidate to a customer’s applicant tracking system?”
“How do I get the payroll runs a company has processed in its payroll system?”
“Can I move a deal to a new stage or change its amount?”
“How do I create an invoice in a connected accounting platform?”
You can see one in the Merge HRIS phrasing overlay.
Getting started
Merge is paid and is a hosted service you call. Start with the HRIS overview and the ATS overview, and there is a support site for Agent Handler. On APIs.io, see the Merge profile, the main Merge API and the Accounting Periods API. Pick the category your customers ask about most and connect that one first.
https://apievangelist.com/2026/10/28/connect-to-your-customers-accounting-hr-and-crm-systems-with-merge/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/connect-to-your-customers-accounting-hr-and-crm-systems-with-merge.png
#get #accounting #crm #merge #systems #ats #unifiedapi #management #hris #post
#rss #feeds #linksharing #qwibbit

2026-10-28 18:23:25 GMT

Send Marketing Email And Manage Contact Lists With SendGrid
If you run a business, you probably need to do two things with email that feel like they should be simpler than they are: keep a clean list of the people you are talking to, and get the right message in front of the right slice of them at the right time. Most people do this by clicking around in a marketing tool. SendGrid lets you do the same work through an API, which is just a way for software, whether it is your own website, a spreadsheet integration, or an AI assistant, to make the request for you instead of you clicking the buttons.
What SendGrid does
SendGrid is a cloud-based email delivery platform, acquired by Twilio in 2019, that handles both transactional email (receipts, password resets, the messages your app sends one at a time) and marketing email (the newsletters and campaigns you send to a list). Beyond sending, it covers contacts and lists, segments, address validation, suppression management (the list of people who should not get mail from you), domain authentication so your mail does not land in spam, and delivery statistics. You can read more on the SendGrid website.
What you can get done
Keep your contacts in one place
The Customer Data Management capability is about the people on your list. When someone signs up on your website or buys something, your software can add them to SendGrid straight away, and update them when their details change, so your list never drifts out of date.
PUT /v3/marketing/contacts adds new contacts or updates the ones you already have.
DELETE /v3/marketing/contacts removes contacts, for example when someone asks to be forgotten.
GET /v3/marketing/contacts gives you a quick preview of recently added contacts.
GET /v3/marketing/contacts/{id} pulls every field stored for one person.
Run your campaigns
The Digital Marketing Management capability covers the campaigns themselves: creating them, reviewing them and cleaning up the old ones.
POST /v3/campaigns creates a marketing campaign.
GET /v3/campaigns lists the campaigns you have created.
GET /v3/campaigns/{campaign_id} shows the content and settings of one campaign.
DELETE /v3/campaigns/{campaign_id} removes a campaign you no longer need.
Talk to the right slice of your list
Customer Segmentation Management is how you stop sending everything to everyone. A segment is a saved filter, such as “customers who bought in the last month”, that keeps itself up to date as your contacts change.
POST /v3/marketing/segments/2.0 builds a segment from a query.
GET /v3/marketing/segments/2.0 lists the segments you have built.
PATCH /v3/marketing/segments/2.0/{segment_id} renames a segment or changes its rules.
GET /v3/marketing/segments/2.0/{segment_id} shows how a segment is defined, with sample contacts.
Give each team or client its own account
If you are an agency or have several brands, Tenant Provisioning & Lifecycle lets you run separate subusers under one parent account.
GET /v3/subusers lists the subusers under your account.
POST /v3/subusers creates a new subuser for a customer or team.
PATCH /v3/subusers/{subuser_name} switches a subuser off or back on.
DELETE /v3/subusers/{subuser_name} deletes a subuser permanently.
Workflows that put it together
A workflow is a recipe: several of those calls, in order, that together finish a real job. APIs.io catalogs 19 of them for SendGrid, including:
Campaign Test Then Send creates a campaign, sends a test to yourself, then sends it for real.
Create List and Add Contacts makes a list, loads contacts into it and confirms they landed.
Create and Schedule Single Send drafts a one-off email, schedules it and reads it back.
Create Segment From List builds a list, filters a segment from it and refreshes it.
Ask for it in plain language
We have written a conversational overlay for SendGrid that maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“How do I add new contacts or update existing ones in Marketing Campaigns?”
“How can I delete several marketing contacts at once by their IDs?”
“How do I build a segment of contacts using a SQL-style query?”
“Can I temporarily switch off a subuser without deleting it?”
“Which campaigns have I created in legacy Marketing Campaigns?”
You can see one of them in the SendGrid Account API phrasing overlay.
Getting started
SendGrid is freemium with a free trial and self-serve signup, and it is a hosted service, so you call their endpoint rather than running anything yourself. The documentation lives on the Twilio site, including the references for alerts and API keys. On APIs.io you can browse the SendGrid profile, along with the Account API and Alerts API. If your list lives in a spreadsheet today, start by getting it into SendGrid contacts, and everything else builds from there.
https://apievangelist.com/2026/10/28/send-marketing-email-and-manage-contact-lists-with-sendgrid/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/send-marketing-email-and-manage-contact-lists-with-sendgrid.png
#marketing #email #get #sendgrid #management #delete #post #run #customer #segmentationmanagement
#rss #feeds #linksharing #qwibbit

2026-10-28 17:50:42 GMT

Send Contracts For Electronic Signature And Track Them With Docusign
Getting a contract signed should not mean printing, scanning and chasing people by email. If your business sends the same agreements over and over, whether offer letters, service contracts or rental agreements, you want them to go out automatically, get signed, and come back filed, with someone told when it is done. Docusign does this, and it does it through an API, which means your own software, your CRM, or an AI assistant can send and track agreements for you without anyone opening the Docusign website.
What Docusign does
Docusign says it helps organizations connect and automate how they prepare, sign, act on, and manage agreements, as part of what it calls the Docusign Agreement Cloud, which includes eSignature. Beyond signing, its APIs reach into web forms, notary, contract lifecycle management (CLM) and Navigator for working with agreements after they are signed. You can find out more on the Docusign website.
What you can get done
Send and manage agreements
The Contract Management capability is the heart of it. Docusign calls a package of documents sent for signature an “envelope”. Your software creates one from a template, fills in who needs to sign, and can find it again later.
POST /accounts/{accountId}/envelopes creates an envelope from a template or your own documents.
GET /accounts/{accountId}/envelopes searches envelopes by date, status or text.
GET /accounts/{accountId}/envelopes/{envelopeId} shows an envelope’s sender, recipients and documents.
PUT /accounts/{accountId}/envelopes/{envelopeId} changes an envelope’s subject or message.
Hear about it the moment something is signed
Webhook & Event Subscription Management is how you stop checking. A webhook is Docusign calling your system when something happens, such as an envelope being completed, so your records update on their own. Docusign calls this Connect.
POST /v2/accounts/{accountId}/connect sets up real-time status updates pushed to your server.
GET /v2/accounts/{accountId}/connect lists the Connect configurations on your account.
PUT /v2/accounts/{accountId}/connect changes where an existing configuration sends updates.
GET /v2/accounts/{accountId}/connect/{connectId} shows the events and address one configuration uses.
Control who can do what
Identity & Access Management matters as soon as more than a handful of people are sending agreements. It lets you manage users, groups and permission profiles across your organization.
GET /v2/organizations/{organizationId}/accounts/{accountId}/permissions lists an account’s permission profiles.
GET /v2/organizations/{organizationId}/accounts/{accountId}/groups lists the groups in an account.
POST /v2/organizations/{organizationId}/users/profiles updates people’s profile details.
DELETE /v2/organizations/{organizationId}/users/{userId}/accounts removes someone’s access, for example when they leave.
Set up and look after accounts
Tenant Provisioning & Lifecycle covers the accounts themselves, useful if you offer signing to your own customers.
POST /v2/accounts creates new eSignature accounts.
GET /v2/accounts/{accountId} shows an account’s basic details.
GET /v2/accounts/{accountId}/billing_charges lists recurring and usage charges.
DELETE /v2/accounts/{accountId} closes an account.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. APIs.io catalogs 18 for Docusign, including:
Bulk Send From Template sends one template to a whole list of recipients.
Correct Recipient Email and Resend fixes a mistyped email address and sends again.
Create Template and Send Envelope makes a reusable template and sends from it.
Download Completed Documents confirms an envelope is done and downloads the signed PDF.
Ask for it in plain language
Our conversational overlay for Docusign maps everyday questions to the operation that answers them, so an AI assistant knows which call to make. These are the kinds of things you can ask:
“How do I create an envelope from a template and fill in the template roles?”
“How do I get real-time envelope status updates pushed to my server?”
“How do I remove a user’s access to specific accounts in my organization?”
“What recurring and usage charges are on my account?”
“How do I programmatically create a new DocuSign account for a customer?”
You can see one in the Account Brands phrasing overlay.
Getting started
Docusign is paid, with self-serve signup, and it is a hosted service you call. Its developer documentation includes the Web Forms API reference and the Notary API, plus a guide to authentication. On APIs.io, see the Docusign profile, the Web Forms API and the Navigator API. Pick the one agreement you send most often, turn it into a template, and automate that first.
https://apievangelist.com/2026/10/28/send-contracts-for-electronic-signature-and-track-them-with-docusign/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/send-contracts-for-electronic-signature-and-track-them-with-docusign.png
#docusign #accountid #get #connect #management #post #send #organizationid #contractmanagement
#rss #feeds #linksharing #qwibbit

2026-10-27 22:46:33 GMT

Share Files And Add Maps, Places, And Routes To Your Business With Google
Most businesses already use Google every day, for documents, for maps, for finding customers and getting to them. What fewer people realize is that much of that is available as APIs, which let other software, or an AI assistant, do the work for you: share the right file with the right person, turn an address into a point on a map, or plan a delivery route. Google is a huge provider, so this post sticks to a few practical jobs. The full picture is on the Google profile on APIs.io.
What Google does
Google needs little introduction. The part of Google this profile describes is Google Docs, the online word processing and PDF editing tool inside Google Workspace, with real-time collaboration and Gemini features for drafting and formatting, offered to individuals, small businesses, startups, and enterprises. Beyond Workspace, Google publishes APIs across cloud, maps, places, and search. More at google.com.
What you can get done
Identity & Access Management
Who can see and edit which file. When a new client comes on, or a contractor leaves, sharing should change everywhere at once, not one document at a time.
GET /files/{fileId}/permissions lists who has access to a file.
POST /files/{fileId}/permissions shares a file with a person or group.
GET /files/{fileId}/permissions/{permissionId} shows one person’s access.
PATCH /files/{fileId}/permissions/{permissionId} changes that access, for example from editor to viewer.
DELETE /files/{fileId}/permissions/{permissionId} removes someone’s access.
Maps, places, and routes
If your business delivers, visits customers, or helps people find a location, Google’s location APIs do the heavy lifting.
The Geocoding API turns a street address into map coordinates, and back again.
The Routes API plans how to get from one place to another.
The Places Insights API and the Aggregate Places API help you understand the businesses and places in an area, useful when you are choosing where to open or advertise.
The Elevation API and the Street View Imagery API add terrain and street-level views.
Running your own APIs
If your business publishes its own APIs, Google Cloud API Gateway puts a managed front door on them, handling who can call them and how.
Getting started
Google is listed as free with self-serve signup, though individual products have their own pricing once you go past free use. Start with the Google Maps Platform documentation, the Places Aggregate documentation, and the API Gateway reference. Browse the Google Maps API and everything else from the Google profile.
Pick the one repeated chore, sharing files or looking up addresses, and let software take it from there.
https://apievangelist.com/2026/10/27/share-files-and-add-maps-places-and-routes-to-your-business-with-google/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/share-files-and-add-maps-places-and-routes-to-your-business-with-google.png
#google #api #places #maps #files #add #googleworkspace #apigateway #access #routesapi
#rss #feeds #linksharing #qwibbit

2026-10-27 20:55:49 GMT

Compare USPS, UPS, FedEx, And DHL Shipping Rates With SMKlog
If you ship parcels from the US, you have probably done this: open four carrier websites, type the same box dimensions into each, and compare prices by hand before buying a label. SMKlog does that comparison for you, and it also offers it as an API, a way for your own software, or an AI assistant, to ask for the prices directly. Their listing is on APIs.io.
What SMKlog does
SMKlog is an independent US parcel shipping calculator and label seller, run by SMKLOG-2022 LLC in Berkeley Heights, New Jersey. You describe an item in plain words and get live USPS, UPS, FedEx, and DHL Express rates from a US origin to the US, Canada, the UK, Germany, or Australia, then buy the label online. More at smklog.com.
What makes SMKlog interesting is how deliberately it is built for machines as well as people. The same pricing engine behind the website is published as the SMKlog Quote API, and it needs no key to try. There is a remote MCP server, which is the way AI assistants plug into tools, with five tools, plus an agent card so other agents can discover it, and a set of published Agent Skills and an llms.txt file to tell assistants how to use it. There is a clear line drawn, too: agents can price a shipment and prepare checkout, but a human always completes payment on smklog.com. I like that line a lot.
What you can get done
Logistics Operations Management
The business outcome here is simple: know what a parcel will cost to send, across carriers, before you commit. That matters for setting shipping prices at checkout, for choosing a carrier on each order, and for answering a customer who asks what it would cost to send something abroad.
POST /quote prices one parcel from a US origin across USPS, UPS, and FedEx, plus DHL Express for international destinations.
One call does one job, and it is the job most people actually came for. Around it, SMKlog organizes its surface into three APIs: Quotes for pricing, Checkout for preparing a label purchase, and Operations.
Why this matters if you are not a developer
You do not have to write code to benefit. Because SMKlog works with AI assistants directly, you can ask an assistant connected to it something like what it would cost to ship a pair of boots from New Jersey to Toronto, and the assistant can call the quote for you and lay out the options. When you are ready to buy, you finish the purchase yourself on the website. The assistant does the comparing; you do the paying.
Getting started
Start with the SMKlog API page. If you or someone on your team writes code, there are SDKs for JavaScript on npm, Python on PyPI, and Go. You can see the Quotes API and the Checkout API from the SMKlog profile.
Next time you are about to open four carrier tabs, ask for one quote instead.
https://apievangelist.com/2026/10/27/compare-usps-ups-fedex-and-dhl-shipping-rates-with-smklog/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/compare-usps-ups-fedex-and-dhl-shipping-rates-with-smklog.png
#smklog #dhlexpress #ups #api #newjersey #quote #fedex #checkout #berkeleyheights
#rss #feeds #linksharing #qwibbit

2026-10-27 19:47:27 GMT

Why I Forked Spectral, And Why It Became OpenLint
I get asked why I forked Spectral. The honest answer is that I almost did it the wrong way, by myself, for my own reasons. What came out instead is OpenLint, a community fork with a name, a formal specification, a home at Open Source Europe, and a weekly office hours that I’ve been hosting since September. Four calls in, I want to write down the why.
Spectral became a standard nobody wrote down
Spectral is the open-source linter Stoplight created, and SmartBear now owns. Over the years its ruleset format quietly became the way the API world writes down its design rules. Governments publish their national API design rules as Spectral rulesets. Banks and enterprises run them in CI. Other tools import them. When I study how companies govern their APIs, a Spectral ruleset is usually where the rules actually live.
But the format was never specified. It is whatever the Spectral CLI happens to do. Development has slowed, and the direction depends on one vendor’s priorities. That is a fragile place to keep something that so many public institutions and companies depend on.
The fork I almost made
I didn’t come to this as a standards project. I came to it as a builder. I was building an API and an MCP server for API Evangelist, with linting at the center of it. The idea was an open-source server you run and own yourself, with a support package around it: I’d help you configure it with your rules and style guides, and build a set of skills for how your teams work. I needed Spectral to go places it wasn’t going, so I was going to soft-fork it and take it down my own path.
I kept having the same conversation at company after company, though. Lots of teams have implemented Spectral rules. Other than keeping them in Git and running a VS Code plugin, very few have any way to distribute them: how rules are versioned, updated and evolved across teams. Everyone had the same itch, and a private fork would have scratched it for exactly one person. I saw that being a bad decision. A fork only one company maintains is the same problem Spectral has, with a different name on it.
So instead of forking it for me, we forked it for everyone.
A community fork, done carefully
The work started under API Commons as “Spotlight” back in July, and took the OpenLint name by community vote in September. I’ll admit it isn’t the name I would have picked. I liked Swagger and I liked Spectral, the flashier names. But I lived through Swagger becoming OpenAPI, and I watched a boring, explainable name win. OpenLint is something you can explain to people who don’t know what an API or a linter is.
A few decisions from the first office hours shaped what kind of fork this is:
Not a GitHub fork button. We started a new repository that carries Spectral’s full history, so fixes can still be cherry-picked across, without the “forked from” framing that implies we’re just trailing upstream.
Spectral’s license carries forward, because it has to. Existing Spectral rulesets are meant to keep working.
The vendorisms come out. Rules that crept in from Speccy and Stoplight and have nothing to do with validity get cleaned out of the default ruleset. We say vendorism rather than Stoplightism, because we don’t want any vendor pulling the project toward itself down the road, including the ones in the room.
AI use stays minimal and agreed per pull request, not used to write issues.
SmartBear is welcome. There has been talk of donating Spectral to the group. We’re not waiting on it, and if they keep building Spectral, the goal is for it to conform, along with Vacuum, Speakeasy and everyone else.
The specification is the point
The most important part of this work is taking what is really just a configuration of a CLI and making it a formal specification, with normative wording, versioning, and a process. Last week the group merged a formal draft, now published at spec.openlint.org, along with tooling that compiles it and runs conformance tests against the current implementation. It also records, inline, every place where behavior had to be reverse-engineered from Spectral instead of read from documentation. There are a lot of them, which is the whole argument for doing this.
A specification is what lets any tool, open source or commercial, say it conforms. It’s what lets a government cite it in procurement. And research we’ve done on rulesets shows most teams use the default ruleset unchanged, so the defaults the specification sets will end up being the API design rules most of the world actually runs.
Back to what I needed it for
The thing that pushed me toward forking in the first place is now on the roadmap in the open. There is an MCP server in progress, designed MCP-first rather than generated from an API. People are building agent skills that run linting and open pull requests for the easy fixes. And the distribution problem, versioning and shipping rules to teams and to their agents, is now a shared problem with a lot more people working on it than just me.
I’m also curious where this goes beyond API design. If you can constrain what a model produces to a schema like FHIR or ISO 20022, rules on top of that schema could check that the data meets a team’s criteria, not just the shape. That’s a side experiment for now, but it’s the kind of thing a rules standard makes possible.
Come help
The code is at github.com/openlint/openlint, the conversation is at github.com/openlint/community, and the office hours are open, recorded and transcribed on openlint.org. If your organization depends on Spectral rulesets, you depend on this work, and the Open Collective is where you can help fund the maintainers doing it. I forked Spectral because I needed to. It became OpenLint because everyone else needed to as well.
https://apievangelist.com/2026/10/27/why-i-forked-spectral-and-why-it-became-openlint/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/why-i-forked-spectral-and-why-it-became-openlint.png
#rss #feeds #linksharing #qwibbit

2026-10-27 19:13:49 GMT

Writing the MCP Style Guide for the Tools an Agent Reads First
Every mature API has a style guide. Two pages on how to name a path, shape a response and report an error do more for consistency than a hundred lint rules nobody reads. Almost no MCP server has one. I think that is a mistake, and it is a more expensive mistake than it was with APIs.
A developer reads your documentation once and remembers it. An agent reads your tool list every time it connects, in full, and pays for it in tokens on every turn. Every inconsistency in that list is paid for again and again. So I wrote the style guide down. The MCP Style Guide is the newest API Evangelist paper.
I started with our own servers
I did not want to write this from first principles, so I started with the two MCP servers we run: APIs.io and API Evangelist. Together they have 212 tools. They were built by the same practice, against the same conventions, within months of each other. I called every tool list, prompt, resource and refused call, and read what came back.
They disagree with each other. Nine tool names exist on both servers, and some of them do not mean the same thing. One of them is free on one server and costs five cents a call on the other. Tier labels are typed by hand and drift from the gates that enforce them. Pagination works two different ways on the same server. A refused call on one server names the plan, the price and a route forward for the agent and the human it works for. The same refusal on the other server returns a bare unauthorized. Neither server declares structured output.
None of that is hard to fix. That is the point. Without a written convention, even one team drifts.
Then I looked at the catalog
APIs.io tracks every public MCP server it can find. I read the names of 103,737 tools across 4,439 servers, and the full definitions of a sample of 1,227 tools captured live from public endpoints. The catalog shows the same drift, at market scale.
Seventy-one percent of tool names are snake_case. The rest split across camelCase, PascalCase, kebab-case and a long tail of everything else, and 228 servers mix styles inside a single tool list.
2,787 tools across 315 servers are named after an HTTP method. That is what an OpenAPI looks like when it is turned into tools without anyone renaming them.
A quarter of servers use three or more different verbs to mean “read.”
Half of all input arguments in the sample have no description at all.
Only about one tool description in eight says when to use the tool instead of its neighbor.
Fewer than one server in three declares structured output.
The median server’s tool list costs about 4,300 tokens. One in ten costs more than 47,000.
The median server is in decent shape. The long tail is where a style guide earns its place.
And I read what providers are saying
I also went through what providers in the network have been writing about MCP. Axiom has the most concrete advice I have seen on keeping responses small by default, with numbers behind it. Kong makes the case against one tool per operation at enterprise scale. Atlassian reports that about a third of the five million tool calls its server handles each working day are writes, which means write design is not an edge case. Atlassian also found agents preferred a CLI over its MCP server once both existed, and the lesson they took was to measure the whole task and build every surface from the same handlers.
What is in the paper
The paper turns all of that into fifty-five numbered rules across naming, descriptions, input schemas, output, errors and refusals, annotations, context budget, prompts and resources, and versioning. Each rule is tied to the evidence that motivated it. There is a list of anti-patterns, a fourteen-question self-assessment, and the full set of rules as a checklist you can turn into a ruleset for your pipeline.
It sits between two earlier papers. Publishing a Public MCP Server covers whether and how to ship one. MCP Documentation Beyond Reference covers the behavior an agent needs to know about. This one covers how the surface itself should read.
There is no such thing as agentic governance. This is the same style-guide work web, mobile and partner integrations always needed, done well enough that a machine can consume it. The machine just does not forgive what a human would work around.
The MCP Style Guide is $25 at papers.apievangelist.com, PDF and Word. We are already working through the rules against our own two servers. If you want to know how yours measures up, let’s talk.
https://apievangelist.com/2026/10/27/writing-the-style-guide-for-the-tools-an-agent-reads-first/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/writing-the-style-guide-for-the-tools-an-agent-reads-first.png
#styleguide #mcpstyle #readsfirst #agentreads #apievangelist #every
#rss #feeds #linksharing #qwibbit

2026-10-27 18:40:05 GMT

Run Your Catalog, Pricing, And Customers In Software With BigCommerce
If you sell online and your store keeps growing, the questions change. How do I give wholesale customers different prices? How do I make sure tax is calculated right on every order? How do I bring back shoppers who left items in their cart? BigCommerce answers those through APIs, which let other software, or an AI assistant, manage your store for you rather than someone working through the admin screens one page at a time. Here is their APIs.io profile.
What BigCommerce does
BigCommerce is an e-commerce platform with APIs for building and managing online stores, products, catalogs, orders, customers, checkouts, payments, and shipping. BigCommerce says it powers tens of thousands of online stores and calls its approach open SaaS: a hosted store you do not have to run yourself, but one you can reach into with code. More at bigcommerce.com.
What you can get done
Item Master Data Management
Keeping your catalog organized, starting with the categories shoppers browse.
GET /catalog/categories lists your categories.
POST /catalog/categories creates a category.
PUT /catalog/categories/{category_id} updates one.
DELETE /catalog/categories removes categories.
Price List Management
A price list is a set of prices for a particular group, such as wholesale buyers or a regional market. This is how one store serves different customers at different prices.
GET /pricelists lists your price lists.
POST /pricelists creates one.
PUT /pricelists/{price_list_id} updates one.
GET /pricelists/{price_list_id} gets the details of one.
Indirect Tax Management
Sales tax and similar taxes collected at checkout. A tax quote is the calculated tax for an order before it is final.
POST /estimate estimates the tax on an order.
POST /commit makes a tax quote final once the order goes through.
POST /adjust changes a tax quote, for example after a partial return.
POST /void cancels a tax quote.
GET /tax/rates gets your tax rates.
Customer Data Management
Keeping customer records in step with your CRM, loyalty program, or support desk.
GET /customers lists customers.
POST /customers creates customers.
PUT /customers updates customers.
GET /customers/addresses lists customer addresses.
Digital Marketing Management
Abandoned cart emails remind shoppers about what they left behind, one of the more reliable ways to recover sales. BigCommerce also lets you manage your store blog through the API, under Content Marketing Management.
GET /marketing/abandoned-cart-emails lists your abandoned cart email templates.
POST /marketing/abandoned-cart-emails creates one.
PUT /marketing/abandoned-cart-emails/{id} updates one.
POST /blog/posts publishes a blog post.
Getting started
BigCommerce is listed as paid. The developer documentation covers inventory, locations, and customer segmentation. On APIs.io you can browse the Inventory API, the Promotions API, the Customer Segmentation API, and the Pickup Methods API, all from the BigCommerce profile.
If you only automate one thing first, make it the abandoned cart emails, since that is money already sitting in your store.
https://apievangelist.com/2026/10/27/run-your-catalog-pricing-and-customers-in-software-with-bigcommerce/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/run-your-catalog-pricing-and-customers-in-software-with-bigcommerce.png
#post #customers #tax #get #management #catalog #bigcommerce #marketing #api #price
#rss #feeds #linksharing #qwibbit

2026-10-27 18:05:44 GMT

Manage Products, Orders, And Coupons For Your Online Store With WooCommerce
If you run an online store on WordPress, a lot of your week probably goes to the same chores: adding products, fixing a price on a variation, creating a coupon for a promotion, looking up a customer, and chasing down an order that needs a refund. Doing that by hand in an admin screen works until the store grows. WooCommerce lets you do all of it through an API, which is simply a way for other software, or an AI assistant working on your behalf, to make those changes for you. You can see everything I have catalogued for them on their APIs.io profile.
What WooCommerce does
WooCommerce is an open-source eCommerce platform built on WordPress. WooCommerce describes itself as the world’s most popular open-source option, and whatever the ranking, the practical point is that it turns a WordPress site into a store. Alongside the store itself it provides a REST API for managing products, orders, customers, coupons, reports, webhooks, and store settings, plus a public-facing Store API for building custom storefronts, and webhooks that announce changes as they happen. You can learn more at woocommerce.com.
What you can get done
I map what an API does to business capabilities, the plain-language jobs a business needs done, so you can find the provider by the job and not by the jargon.
Product Lifecycle Management
This is your catalog: getting products into the store, keeping them accurate, and retiring them when they stop selling. If you sync products from a supplier spreadsheet or another system, this is where it happens.
GET /products lists every product in the store.
POST /products creates a new product.
PUT /products/{id} updates a product, such as its price, description, or stock.
DELETE /products/{id} removes a product.
POST /products/batch creates, updates, and deletes many products in one go, which is what you want for bulk changes.
Product Configuration & Variant Management
A t-shirt in three sizes and four colors is one product with many variations, and each one can have its own price, stock, and image.
GET /products/{product_id}/variations lists the variations of a product.
POST /products/{product_id}/variations adds a new size, color, or option.
PUT /products/{product_id}/variations/{id} changes one variation.
DELETE /products/{product_id}/variations/{id} removes one.
Customer Data Management
Keeping customer records in step with your email tool, your CRM, or your support desk.
GET /customers lists your customers.
POST /customers creates a customer account.
PUT /customers/{id} updates a customer, such as a new address.
GET /customers/{id}/downloads shows the digital products a customer can download.
Discount & Promotion Management
Coupons are how most stores run promotions, and creating them in software means a campaign tool can mint codes when it needs them.
GET /coupons lists your coupons.
POST /coupons creates a coupon.
PUT /coupons/{id} changes a coupon, such as extending its expiry.
DELETE /coupons/{id} retires one.
Webhook & Event Subscription Management
A webhook is a message WooCommerce sends to another system the moment something happens, such as a new order. This is how your shipping, accounting, or messaging tools hear about sales without anyone copying them over.
GET /webhooks lists the webhooks you have set up.
POST /webhooks subscribes another system to an event.
PUT /webhooks/{id} changes where or when a webhook fires.
DELETE /webhooks/{id} turns one off.
Workflows that put it together
A workflow is a recipe: several API calls made in a set order to finish one job. These are written in the Arazzo format so software and assistants can follow them step by step.
Create Customer and Order creates a customer account, places an order on their behalf, and reads it back.
Create Order and Refund places an order, marks it completed, and issues a refund against it.
Create Order with Note places an order and attaches an internal or customer-facing note.
Create Product and Targeted Coupon creates a product and a coupon that only works on it.
Create Category and Product sets up a category and a product inside it.
Category, Variable Product, and Variation builds a category, a product with options, and a first variation.
Getting started
WooCommerce is listed as paid. Start with the REST API documentation, read how authentication works, and see the webhooks guide for real-time events. If you prefer GraphQL, there is the WooGraphQL documentation. On APIs.io you can browse the Orders API, the Coupons API, the Order Refunds API, and the Webhook Events, all from the WooCommerce profile.
Pick the one chore that eats the most of your week, find it in the list above, and hand that to software first.
https://apievangelist.com/2026/10/27/manage-products-orders-and-coupons-for-your-online-store-with-woocommerce/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/manage-products-orders-and-coupons-for-your-online-store-with-woocommerce.png
#onlinestore #products #coupons #post #get #woocommerce #orders #customer #management #lifecyclemanagement
#rss #feeds #linksharing #qwibbit

2026-10-27 17:31:12 GMT

Automate Clusters, User Access, And Patching With Red Hat
If you are responsible for the servers and cloud systems your business runs on, the work never really stops: spin up an environment for a new project, give a new hire access, run the same maintenance job across a fleet of machines, and find out which systems still need a security patch. Red Hat lets you do much of that through APIs, which are a way for other software, or an AI assistant, to carry out those tasks for you instead of someone clicking through consoles. Everything I have catalogued is on their APIs.io profile.
What Red Hat does
Red Hat provides enterprise open source software, including Linux, cloud, container, and Kubernetes technologies. Kubernetes is the system many companies use to run their applications in containers across groups of servers called clusters. Red Hat describes itself as a leading provider in that space. Around those products it publishes APIs for subscriptions, cluster management, security, cost tracking, image building, and patching. More at redhat.com.
What you can get done
IT Infrastructure Management
Creating and looking after the clusters your applications run on, so a new environment is a request to software rather than a ticket that waits in a queue.
GET /api/clusters_mgmt/v1/clusters lists your clusters.
POST /api/clusters_mgmt/v1/clusters creates a new cluster.
GET /api/clusters_mgmt/v1/clusters/{cluster_id} gets the details of one cluster.
PATCH /api/clusters_mgmt/v1/clusters/{cluster_id} changes a cluster.
DELETE /api/clusters_mgmt/v1/clusters/{cluster_id} removes a cluster you no longer need.
Identity & Access Management
Deciding who can sign in and how. This covers adding users and connecting the login systems your company already uses.
GET /admin/realms/{realm}/users lists users.
POST /admin/realms/{realm}/users creates a user.
GET /admin/realms/{realm}/identity-provider/instances lists the outside login providers connected.
POST /api/clusters_mgmt/v1/clusters/{cluster_id}/identity_providers connects a login provider to a cluster.
IT Operations Management
Repeatable maintenance. A job template is a saved, reusable automation job, such as updating software across many machines.
GET /api/v2/job_templates/ lists job templates.
POST /api/v2/job_templates/ creates one.
PATCH /api/v2/job_templates/{id}/ changes one.
DELETE /api/v2/job_templates/{id}/ removes one.
Vulnerability Management
Knowing where you are exposed. Errata are Red Hat’s published fixes and advisories for its software.
GET /katello/api/v2/errata lists available errata.
GET /api/v2/hosts/{id}/errata lists the errata that apply to one machine.
GET /repository/{repository}/manifest/{manifestref}/security gets security information for a container image.
Workflows that put it together
A workflow is a recipe of several API calls in a set order that finishes one job.
Build Inventory and Template resolves an organization, creates an inventory, builds a job template on it, and launches a first run.
Provision and Run Job creates a job template, launches it, and follows the job to completion.
Launch, Monitor, and Cancel Job runs an existing job and cancels it if it stalls.
Inspect a System pulls fleet statistics, finds a system by name, and retrieves its detail.
Triage a Rule’s Affected Systems finds a high-risk advisor rule and lists the systems it affects.
Provision Realm Role and User confirms a realm, creates a role, and creates a user in it.
Getting started
Red Hat is listed as enterprise with self-serve signup. Start with the Red Hat management API documentation and read about API authentication. For specific products there is documentation for Advanced Cluster Management and Advanced Cluster Security. On APIs.io, look at the Subscription Management API, the Patch API, the Vulnerability Management API, and the Cost Management API, all from the Red Hat profile.
Start with the patching question, which systems need what, because it is the one that tends to keep people up at night.
https://apievangelist.com/2026/10/27/automate-clusters-user-access-and-patching-with-red-hat/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/automate-clusters-user-access-and-patching-with-red-hat.png
#redhat #clusters #get #api #access #post #management #errata #patch #infrastructuremanagement
#rss #feeds #linksharing #qwibbit

2026-10-27 14:59:05 GMT

Regulation Writes The API
Outside of tech, Australia’s API contracts were written by the regulator.
Yesterday I ranked the most programmable sectors in Australia using 227 of the country’s largest companies. Tech came out on top because it sells its API. Banking and energy landed in the middle of the table, and when I opened up the contracts behind that ranking, the reason was the same almost every time: the Consumer Data Right.
31 companies, one source of contracts
31 of the 227 companies carry a Consumer Data Right signal in their profile — 22 in banking and finance, 8 in energy and utilities, and one elsewhere. And when you look at the contracts the banks and energy retailers publish themselves, nearly every one of them is a Consumer Data Standards contract.
Company
What it publishes
AMP
One contract: CDS banking product data
ANZ
CDS banking product data
Westpac
CDS banking
Commonwealth Bank
CDR accounts, balances, customer and related CDS APIs
NAB
CDS banking product data, plus a gateway payments API
EnergyAustralia
CDS energy and CDS common
Red Energy
CDS energy and CDS common
AGL
CDS energy and CDS common
Origin
CDS energy and CDS common, plus its Kraken platform APIs
AMP is the cleanest example. Its only published contract is its CDR product data. EnergyAustralia, Red Energy and AGL publish the energy standard and the common endpoints that go with it, and that is the whole of their public machine-readable surface. NAB and Origin are the exceptions that prove the rule — they publish one or two things beyond the standard, and that is where the list ends.
Why that is a good thing
This is not a complaint. The Consumer Data Right did something the market never did on its own: it made every bank, and now every energy retailer, publish a contract in the same shape. The same paths, the same schemas, the same security profile, across competitors. That is exactly what an agent needs. An agent that knows how to read one bank’s product data knows how to read all of them.
It is also the clearest evidence I have seen that standards plus a mandate produce programmable markets faster than anything else. The banks did not each design a products API. They implemented one. The energy retailers did not each decide to open up tariff data. They were required to, in a standard everyone shares.
Why it is also a ceiling
The same table shows the limit. When the regulator writes the API, the API stops where the regulation stops.
Product data, not products. Most of these contracts are the public product reference data — what a bank offers, what a tariff costs. The consumer data behind consent sits behind accreditation, which is the point, but it means the open, discoverable surface is narrow.
Nothing beyond the mandate. Outside of NAB’s payments gateway and Origin’s Kraken APIs, the banks and retailers in this cohort publish nothing else. No pricing for developer access, no sandbox for a partner to try something new, no MCP server, no agent card. The CDR contract is the API program.
Action initiation is still waiting. The framework to let accredited apps act on a customer’s behalf, such as making a payment, has been legislated. As far as I can find, no specific actions have been designated yet. Until they are, the CDR is a read surface. Agents want to act.
Where the regulation goes, the APIs follow
The best predictor of which Australian sectors become programmable next is not technology. It is where the Consumer Data Right goes next. It reached non-bank lenders this year, with product data sharing from July and consumer data sharing due in November. Superannuation is outside it, and the six largest super funds publish nothing an agent can use. Telco was designated in 2022, but no rules were ever made and the expansion was paused in 2023. Mining has no equivalent regime, and 41 miners publish one Swagger file between them.
That gives the room at The API Economy Roundtables at apidays Australia tomorrow two questions — regulation, privacy and digital identity are one of the conversations on the agenda. For the regulated sectors: what would it take to publish beyond the mandate, so the CDR becomes the floor of the API program instead of the whole of it? And for everyone else: does Australia have to wait for a regulator to write each sector’s API, or can the market start doing it on its own?
The banking and energy profiles, contracts included, are on APIs.io after this week’s build. If you are in Melbourne on Wednesday, October 28th, come join the roundtables and bring your own answer.
https://apievangelist.com/2026/10/27/regulation-writes-the-api/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/regulation-writes-the-api.png
#cds #consumerdata #api #cdsapis #origincds #westpaccds #apisnab #krakenapis #australia #energyaustraliacds
#rss #feeds #linksharing #qwibbit

2026-10-27 14:23:39 GMT

Telecom Network APIs: The Shape Of The Answer
Last week I wrote about DeepInfer and the shape of the answer, and how batch-invariant inference, deterministic sampling, and schema-constrained output make valid JSON table stakes and move the hard problem to agreeing on the shape. I want to walk that idea through one industry at a time, and I am starting with the one that has done the most to write its shapes down in the open: telecom network APIs.
The answer this industry needs
In telecom the answer a model produces is rarely the end of anything. It is a decision that feeds the next API call. Should this bank transfer trigger a SIM swap check before it goes through, and over what window? Does this login need the network to confirm the phone number, or is the one-time password enough? What quality of service does this video session or remote inspection need, and for how long?
So the business outcome reads like this. Turn a transaction, a login, or a session request into a valid network API request body. Then turn the network’s response into a valid decision your own systems can act on. Both halves have a shape, and in this industry somebody already agreed on it.
The shape is already written down
CAMARA, the Linux Foundation project that defines mobile network capabilities as OpenAPI, publishes each API in its own repository under github.com/camaraproject. GSMA Open Gateway is the operator commitment around those definitions. I read three of them on the main branch today.
SIM Swap has two operations, POST /check and POST /retrieve-date. The check request is a CreateCheckSimSwap with a phoneNumber and a maxAge in hours, an integer from 1 to 2400 with a default of 240. The answer is a CheckSimSwapInfo with one required boolean, swapped. The date operation returns a SimSwapInfo with latestSimChange.
Number Verification exposes POST /verify, which answers with a required devicePhoneNumberVerified boolean, and GET /device-phone-number.
Quality on Demand exposes /sessions, /sessions/{sessionId}, /sessions/{sessionId}/extend, and /retrieve-sessions. A CreateSession takes a device, a qosProfile, and a required duration in seconds. The session comes back with a QosStatus enum of REQUESTED, AVAILABLE, or UNAVAILABLE.
That is about as constrained-decoder-ready as an industry gets. A boolean, a bounded integer, a three-value enum. The one place the shape opens up is QosProfileName, which the spec describes as a string pattern that may be a UUID, a predefined QOS_S, QOS_M, QOS_L or QOS_E, or a descriptive name, with the real list coming from each operator through the QoS Profiles API. That is honest of the spec, and it tells you exactly where the vocabulary has to come from.
On APIs.io, the CAMARA standard page lists 36 providers in the catalog that carry CAMARA, and the GSMA Open Gateway page lists 5. Our CAMARA profile holds 21 of the project’s OpenAPI definitions, from device swap and location retrieval to QoS sessions, QoS profiles, and phone number verify.
What the catalog holds
The Telecom Network APIs market cohort has 25 members, and it splits cleanly into two worlds. The communications platforms lead. Twilio scores 91.6 (exemplar), Telnyx 86.1 with the highest agent readiness in the cohort at 78.6, Infobip 84.9, Sinch 71.5, and Vonage 71.3. The operators sit lower. The highest-scoring carrier is Orange Business at 65.3. Verizon is 56.7, América Movil 55.7, MTN Group 52.1, and AT&T, Telstra, and Kaleyra sit around 43 to 44 at the bottom of the cohort. Aduna, the operator aggregator, is outside the cohort and scores 32.3, thin.
That gap matters for this argument because the CAMARA shapes live with the operators, and the operators publish the least around them. When I searched every provider’s OpenAPI folder for the CAMARA SIM Swap response field swapped, I found SIM or device swap contracts at Orange Business, Telefónica, Telkomsel, América Movil, and Nokia Network as Code, alongside the CAMARA and GSMA definitions themselves. devicePhoneNumberVerified shows up at Infobip, Orange, Telefónica, and Nokia. The QOS_ profile names appear most at 3GPP, then CAMARA, GSMA, Telefónica, Orange, and Nokia. AT&T has SIM Swap, Number Verification, and Quality on Demand contracts too, but those three are ones API Evangelist authored from AT&T’s documentation, not files AT&T published, and I want to be clear about that.
Around the contracts, the supporting artifacts are uneven. Bandwidth carries 71 JSON Schema files, 54 JSON Structure definitions, and 54 examples. AT&T carries 82 schemas and 72 examples. Telnyx has 236 schemas, Sinch 188, Twilio 183, and Twilio is the only cohort member with Arazzo workflows, 29 of them. Most of the operators carry an OpenAPI folder and little else. Swisscom, Optus, Orange Business, MTN Group, and KPN have no JSON Schema, JSON Structure, or examples folder in the catalog that I can find.
What determinism changes here
Three things make deterministic, constrained inference matter more in telecom than in most places.
The first is fraud and audit. A SIM swap check sits in front of money movement and account recovery. If a model decides that a transfer warrants a check with a maxAge of 72, a bank needs to show a regulator or a customer why, and it needs to get the same decision when it replays the same input next month. Batch-invariant, deterministic sampling makes that replay real. A constrained decoder makes it impossible for the model to ask for a maxAge of 5000 or invent a swapped value of “probably.”
The second is the operator boundary. The spec itself notes that an operator may cap maxAge below 2400 because of local privacy rules, and returns 400 OUT_OF_RANGE when you go past it. That is exactly the kind of constraint you add per operator, as an overlay on the CAMARA contract, and then hand to the decoder. The model only produces requests that operator will accept.
The third is volume and cost. Quality on Demand is paid network capacity. A model that maps a session to QOS_L for an hour when QOS_M for ten minutes would do is spending money, and a nondeterministic one spends it differently each time. Constraining the answer to the operator’s own profile list from the QoS Profiles API, and getting the same answer for the same session, turns that into something finance can reconcile.
Where it falls short
The shape is written down. The adoption around it is not. Thirty-six providers carry the CAMARA tag, but only a handful of them have a CAMARA contract I can find in their own published OpenAPI. The aggregator scores thin. The operators that would actually answer these calls sit at the bottom of the market cohort, with few schemas, examples, or workflows around their contracts. GSMA Open Gateway returned a 403 when our market work tried to read it, and Nokia’s supported-networks list is client-rendered, so even the question of who answers which API in which country is hard to get as data.
The other gap is the vocabulary. QosProfileName is deliberately open, so the enum a decoder needs lives in each operator’s QoS Profiles response, not in the standard. I can’t find any operator in the catalog publishing that list as a vocabulary or schema. Until they do, every team building on Quality on Demand will write its own.
Telecom did the hard part already. It agreed on the questions and the contract, in the open, under a foundation. What it needs now is for the operators to publish their side of that contract as completely as the communications platforms publish theirs, so a model can be told exactly what shape the answer has to take, and give that answer the same way every time.
https://apievangelist.com/2026/10/27/telecom-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/telecom-the-shape-of-the-answer.png
#networkapis #shape #answer #telecomnetwork #qos #api #camara #gsmaopen #opengateway #post
#rss #feeds #linksharing #qwibbit

2026-10-27 05:33:23 GMT

The Most Programmable Sectors In Australia
Australia is programmable where it is paid to be, or made to be. Everywhere else, it is dark.
Ahead of The API Economy Roundtables at apidays Australia this Wednesday, October 28th, I profiled 227 of the country’s largest companies — the ASX 200 plus the big private, tech, telco, super and government publishers — through the same enrichment pipeline that feeds APIs.io. 80 were already in the catalog and got re-profiled, 147 were new. For each one I asked a simple question: what does this company publish that a developer, or an AI agent, can actually read?
Not a marketing page. A machine-readable contract (OpenAPI, AsyncAPI, GraphQL, Postman), a developer portal, an MCP server, an agent card, an llms.txt, a sandbox, published pricing, published rate limits. If a company has none of those, there is nothing for an agent to discover, no matter how big the brand is.
Half of the country gives an agent nothing to read
117 of the 227 companies — 52% — publish none of it. That list includes BHP, Rio Tinto, CSL, Wesfarmers, Coles, Fortescue, Woodside, Santos and Transurban. These are the companies that define the Australian economy, and to an agent they are a homepage and a press release.
Ranked by sector
Sector
Companies
Own contract
Nothing for an agent
Tech
25
76%
8%
Government
13
54%
0%
Banks / finance
39
49%
31%
Telco
7
43%
14%
Energy / utilities
16
44%
44%
Health
15
13%
60%
Retail / consumer
22
9%
50%
Industrials / property / media
43
12%
77%
Super funds
6
0%
83%
Mining
41
2%
90%
“Own contract” means the company publishes the contract itself, not one we generated from its docs. Telco and super are small samples, so read those two rows as directional.
Three reasons a sector becomes programmable
It is paid to be. Tech sells its API, so tech publishes everything. 19 of 25 have their own contract, 17 publish pricing, 13 publish rate limits, and six run MCP servers backed by their own API — Xero, Airwallex, SafetyCulture, Linktree, Go1 and Envato among them. This is the only Australian sector that is broadly ready for agents today, and it got there because the API is the product.
It is made to be. Banking and energy sit in the middle of the table for one reason: the Consumer Data Right. 31 companies in the cohort carry a CDR signal. Outside of tech, nearly every contract a bank or energy retailer publishes is its CDR contract. EnergyAustralia and Red Energy publish the Consumer Data Standards energy APIs. AMP’s only contract is its CDR product data. Regulation wrote these APIs. The market, for the most part, has not written any others.
It is told to be. Government publishes because open data is a mandate. 12 of 13 government publishers have a developer portal and seven publish their own contracts — the ATO, ABS, CSIRO, Transport for NSW and Trove among them. But not one of them has an MCP server, an agent card, or OAuth protected resource metadata. Government is open, and it is not yet discoverable by an agent.
Every sector without one of those three forces is dark.
The dark end of the table
Mining is the starkest. 41 miners, one Swagger file — Dyno Nobel’s. 37 of 41 publish nothing at all. And this is not an Australian problem. When I looked for miners anywhere in the catalog with a rich contract, I could not find one. The contracts in mining belong to the suppliers: Caterpillar’s telematics API on ISO 15143-3, Bentley and Seequent for geology, Propeller for drone survey, Benchmark for battery-mineral prices. Miners do not publish APIs. Their suppliers do.
The super funds are the other end of the same story. Superannuation is compulsory, holds roughly four trillion dollars, and touches nearly every working Australian. The six largest industry funds — AustralianSuper, Australian Retirement Trust, Aware Super, UniSuper, Hostplus and Rest — publish no contract, no portal and no sandbox. Superannuation is outside the Consumer Data Right, so nothing is pushing them. Enormous consumer reach, zero programmable surface.
What the agent signals actually say
The AI-era signals are thin, and a lot of what is there was not built on purpose.
llms.txt is the most common signal, at 49 of 227. CommBank, NAB, Westpac, AGL, Origin, QBE and Bupa all serve one. Several come from a careers or investor-relations site rather than the main domain.
Retail’s MCP servers were switched on by Shopify. JB Hi-Fi, Lovisa, Harvey Norman and three others answer at Shopify’s /api/ucp/mcp endpoint. That is real agent commerce surface, and none of them built it.
Three agent cards in 227 companies — Woolworths’ Wpay, Linktree and Immutable — and all three live on a docs site.
A blocked front door is not a closed API. 21 companies put an anti-bot challenge in front of their homepage, including BHP, Macquarie, QBE, AGL and the ATO. Macquarie, QBE, the ATO and AGL still publish contracts behind it. An agent that gives up at the homepage never finds them.
Why this matters this week
Australia is moving quickly on agents. The banks are publishing guardrails for agentic commerce, NAB is testing a customer-facing agent platform, and Google launched agentic checkout here first in Asia-Pacific. All of that assumes the agent can find something to act on. For most of the ASX 200, today, it cannot.
The pattern also says where the next wave comes from. If regulation is what made banking and energy programmable, then the extension of the Consumer Data Right — to non-bank lenders now, and possibly to other sectors next — is the single biggest lever on how programmable Australia becomes. And for the sectors outside it, the question for the roundtable is a commercial one: what would make a miner, a super fund or a retailer want to be found by an agent?
If you are going to be in Melbourne, join us at The API Economy Roundtables on Wednesday — first a session on using the Kin Score in the Australian and ANZ region with Claire Barrett and myself, then The API Economy in an AI-everywhere world with Will Fettke from Telstra and Erik Tveitnes from REA Group. These are the numbers we will be putting on the table.
All 227 profiles are on APIs.io after this week’s build. If your company is one of them and the catalog has it wrong, tell me — I would rather fix it than be right about the pattern.
https://apievangelist.com/2026/10/26/the-most-programmable-sectors-in-australia/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-most-programmable-sectors-in-australia.png
#australia #own #api #sector #energy #companies #tech #government #data #mcp
#rss #feeds #linksharing #qwibbit

2026-10-27 04:57:52 GMT

Start With The Flow, Not The Agent
A lot of companies are asking me some version of the same question right now. We want our operations to be programmable for agents, so do we need MCP, or A2A, or both? It is the wrong first question. Here is the advice I keep giving, in the order I would actually do it.
Agents are not new, they are a more persistent client
There is a story going around that web APIs were made for humans and MCP is made for agents. That is not true. We have been trying to automate API discovery, onboarding and consumption for as long as I have been doing this. We had hypermedia. We have always had a User-Agent header. What is new is a smarter client, a far more persistent client, and a business environment where agents are knocking on your door whether you invited them or not.
That pressure is useful. It is finally forcing providers to publish what I have been asking for over the last sixteen years: complete OpenAPI with examples, a well-known API catalog, machine-readable OAuth metadata, published rate limits, published pricing and plans, and now an A2A card. None of that is new work. It is overdue work.
Map the flow, step by step, before you pick a protocol
I can’t tell you whether you need MCP or A2A without seeing the whole flow. Who initiates each step? What is request and response? What is an event, a webhook, a message on a queue? What is a long-lived connection? Which steps are kicked off by an agent, and which by a system reacting to something that already happened?
Agents are just the loop on one end of all of that, making requests. MCP is, in my book, an API: JSON-RPC over a long-lived HTTP connection, something we had long before MCP. A2A is the card and the exchange that lets two parties see what each other has and start talking. They are each one piece. Walk every step of the flow across every party involved, and the protocol for each step usually becomes obvious. Most of the time it is the API patterns we already have.
Own your side, and publish it
When more than one company is involved, you only get to own your side. You can’t own your partner’s infrastructure or your customer’s. What you can own is your API resources, your events, your agents, and the front door that tells everyone else what is available:
An A2A card, so other agents can see your skills.
A well-known API catalog at the root of your domain.
OAuth metadata, so a client knows how to get access before it asks.
MCP server cards, if you run MCP.
Complete contracts behind all of it, starting with your APIs and your events.
That combination is what lets a counterparty’s agent find you, understand you and connect, without a meeting.
Think in business capabilities
Your company needs to be capable of doing something. That capability is not just the technical details. It is the regulation, security and compliance wrapped around the process, all the things you have to own to deliver it. A2A sits next to REST, webhooks and events as one way of exposing that capability. The enterprises getting this right are approaching agents as a business capability question first, and a protocol question second.
Security already has most of the answers
You do not need to invent trust for agents from scratch. OAuth gives you authentication, who the client is, and authorization, what it can reach, down to which resources and fields come back through scopes. OpenID Connect sits on top of that. If you handle money or regulated data, look hard at FAPI 2.0, the financial-grade profile of OAuth, which brings the signing and checks you are going to need.
Then publish it. Put your OAuth and protected resource metadata in your well-known directory, next to your API catalog and A2A card. That is how a partner learns what is possible and what they do and do not have access to.
The new layer is bot identity. Not just does this client have a token, but who does this agent represent, a user or a company, and how far can you trust it? Think of it as know-your-agent, the same way banks think about know-your-customer. On APIs.io I broker exactly this: a consumer agent proves control of its domain, APIs.io attests to it, and the provider decides whether to accept that attestation.
Design for constant failure
Agents fail constantly, and they fail forward. They will try the same thing two, three, fifteen times, even when they have everything they need. This changes a few things:
Idempotency on every call. It used to be something you put on create payment so you did not charge a card twice. Now it belongs on every write, because the agent will ask again and you need that record created once.
Standard errors. Use Problem Details for HTTP APIs. Fail fast, fail consistently, and say as much as you can about what is wrong and what is needed next.
Standard contracts. If your contract uses the standards a model already knows, it has less to guess. If it doesn’t, it will make things up and keep trying.
The smaller, local models fail more than the frontier ones, which is a good reason to test against them. They show you where your APIs lean on the client being clever.
Do not assume the standards are finished
The biggest misconception I run into is that A2A and MCP are done. They are not. Go sit in on the working group meetings. The people writing these specs are experts, and they are still working a lot of it out in the room. Much of what you might assume is settled infrastructure is still being decided, and some of it is wheels we already built in API land, being rebuilt. Know that before you roll out a lot of infrastructure and beat yourself up over what is missing.
Let agents help design your APIs
I have always designed APIs first, with OpenAPI and AsyncAPI, iterating with consumers and mock examples before writing code. That process now includes agents as consumers. For APIs.io I run an agent for each access tier. Every day it tries to use my APIs and MCP servers and files what it hits as GitHub issues. Another agent acts as product manager, triages those issues and gives me a roadmap, which I work through with it.
Give your agents a sandbox, especially if you are regulated. Give them skills that define who they represent and how they work. Have them log everything and count how many calls it took to get something done. They will see things in your portal, docs, onboarding and auth that humans do not. Keep the human design process too. You need both.
Keep humans in the loop on purpose
I try to minimize the human in the loop, but not to zero. Three places I bring people back in:
Money. When a payment is set up or made, a human approves it.
Error thresholds. After five or ten failed tries the agent stops and posts to Slack or Teams. You do not want your own agent hammering an API, especially one with rate limits or costs.
Improvements. If an agent thinks something could be better, it files a labeled GitHub issue rather than acting on it.
Don’t forget the API roots
I am biased, but the API patterns you already know will save you: REST, RPC, events, webhooks, queues. Not everything needs to be an agent, and it is easy to get blinded by AI. Make as much of the flow as deterministic as you can, and keep the parts where a model makes decisions as small as you can. Map the flow, own and publish your side, secure it with what already works, and design for agents that will fail forward a thousand times a day.
https://apievangelist.com/2026/10/26/start-with-the-flow-not-the-agent/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/start-with-the-flow-not-the-agent.png
#mcp #agents #api #flow #own
#rss #feeds #linksharing #qwibbit

2026-10-27 04:25:41 GMT

A Meter With No Rate On It
Salesforce is going to charge Flex Credits when AI agents call into a production org. Every successful call a registered agent makes, over MCP or straight through the API, gets counted as a “Headless Platform Interaction” and draws down credits. Salesforce Ben has the details: traditional integrations stay as they are, sandboxes and Developer Edition orgs aren’t metered, and nothing is being billed yet. Customers get 30 days’ notice before it starts. The rate card lists the price as “TBA.”
This lit up LinkedIn the way you’d expect. A HubSpot partner called it a tax on AI adoption. Peter Caputa asked whether we hadn’t already settled the “should we charge for API access” debate. And Sean Matthews, who has spent his career on API platforms and integrations, asked what I think about API and MCP monetization these days. Here’s the long answer.
Charging at the interface isn’t the problem
I’ve been tracking API plans, pricing and rate limits for fifteen years, and I don’t think metering access is wrong. Metered tiers, overage pricing and rate limits as a product lever are all old and well understood. Sean is right that agents are putting real load on systems that were never a meaningful cost center, and the people running the numbers follow the usage wherever it goes. A provider is allowed to price that.
Three things about this one bother me, though.
1. The price isn’t published
A meter without a published rate isn’t a pricing model. It’s a blank check with 30 days’ notice. Sean’s whole argument is that pricing should shape behavior, nudging people toward what you want and away from what you don’t, and that only works if people can see the price. An agent can’t budget against a number that doesn’t exist, and neither can the person approving the agent. Salesforce has said as much: the agents decide how many calls they make. So the one party that can’t predict usage is being handed a meter it can’t read.
Publishing the rate is the easy part. Look at the providers people already trust with agents and you’ll find their plans and rate limits written down where a person or a machine can read them. Some now put the price right in the tool definition. A couple of weeks ago I found five MCP servers putting a price in the tool in four different shapes. Those are small companies working this out in public. A company the size of Salesforce can publish a number.
2. It meters the protocol, not the value
Charging for an MCP call the same as an API call says the interface is the product. It isn’t. The record, the workflow and the outcome are what a customer pays Salesforce for. The interface is just how they get there. Sean put it well: figure out pricing within the product and the service, not at the interface boundary. Price what the call accomplishes and you can steer behavior toward the expensive, valuable things and away from the cheap, wasteful ones. Price the call itself and you charge the same for an agent doing something useful as for one stuck in a retry loop.
This is where entitlements come in. A plan should tell you what you’re allowed to do and what it costs, and that should hold no matter how you reach it: a person in the UI, an integration, or an agent. If the price changes when the protocol changes, the protocol has become the product.
3. Agent identity is right, and it shouldn’t come with the bill
Giving agents their own identity, permissions and limits, instead of letting them borrow a person’s, is exactly what every platform should be doing. It’s the most important governance move of the agent era, and Salesforce deserves credit for making it a requirement. HubSpot’s agents still run on a user’s permissions, and they should fix that.
Tying the meter to registration makes good governance look like a toll booth. If registering your agent is the moment you start paying, people will put off registering, wrap agents in user credentials, and route around the identity layer that makes agents safe to run. The meter gets a free ride on a feature nobody can argue against, and the feature takes the reputational hit.
What the catalog shows
I wanted to know whether Salesforce is an outlier or a sign of where things are going, so I measured it. On APIs.io we keep plans and pricing, rate limits and FinOps profiles for every provider. I counted only the plans transcribed from a provider’s own pricing page: 4,986 of them. Our generated estimates were left out.
145 providers mention MCP or agent access inside a plan and don’t charge for it separately. The MCP server, the agent integration or the tool access comes with the subscription, the seats or the credits a customer already pays for.
7 providers price AI-agent, MCP or tool-call access as its own unit, and 5 of them publish the number. Seekr charges $0.0135 per tool call for web search. CodeRabbit charges $0.40 per agent minute, SLNG a fraction of a cent per agent minute, and Chatbase $25 per extra AI agent a month. Anvilogic charges one credit per MCP tool call. A lot of plans also say “per agent”, but they mean human support agents or CI build agents, so I left those out.
129 providers publish a rate limit scoped specifically to MCP or agent traffic, and 82 of them put a number on it. Ada limits its MCP server per AI agent per second, minute and day. Datadog caps MCP tool-call bursts. Relevance AI sets a per-call MCP limit.
So the market has mostly bundled agent access into what customers already pay for. Where it meters agents separately, it publishes the rate. And far more providers manage agent load with a published rate limit than with a price. I couldn’t find another provider in the catalog that meters agent calls the same as API calls and leaves the rate blank. That combination is Salesforce’s.
What I’d do instead
Keep the agent identity, and make it free. Publish the rate before the 30-day clock starts, in the plan and on the rate card, and somewhere a machine can read it. Price the outcomes and entitlements your customers value, the same way for every way of reaching them. And treat call volume as a rate limit to manage, not a revenue line to optimize.
The question isn’t whether agents should pay their way. It’s whether the people who have to approve them can see what it costs before they hit the button. Right now they can’t. Salesforce has the identity part right. Publish the number, price the value instead of the call, and this stops being a story.
https://apievangelist.com/2026/10/26/a-meter-with-no-rate-on-it/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/a-meter-with-no-rate-on-it.png
#rate #api #price #mcp #salesforce #flexcredits #sean #developeredition #headlessplatform #platforminteraction
#rss #feeds #linksharing #qwibbit

2026-10-27 03:52:01 GMT

The Specification Layer Now Has a Home
For twelve weeks I’ve been reading a set of specification repositories every Monday and writing up what actually changed in them — not what was announced, what merged. That work now has a home on the API Evangelist standards site: The Specification Layer, a single page that lists every specification I follow, links to the newsletter that reports on them, and lays out the alignment work I do alongside the people who maintain them.
Why a page
Most of what an API is built on is decided in a small number of repositories and the calls around them. OpenAPI 3.3 gained a new top-level keyword last week, A2A’s draft changed how agents are discovered, and SLSA defined a new build level — and almost none of that showed up in anyone’s feed. The newsletter exists to catch it. The page exists so the list itself is public: if you want to know what I’m watching, or argue that I’m watching the wrong things, it’s all in one place.
What’s on it
Fifty-two specifications in seven groups, each with who stewards it, where it lives, and its entry in the standards catalog:
The description layer — OpenAPI and its new security companion specification, Arazzo, Overlays, AsyncAPI, GraphQL, JSON Schema, Protocol Buffers, gRPC and Open Resource Discovery.
AI & Agents — a new group as of today: MCP and its registry, A2A, the AI Catalog, ONNX, OASF, AGENTS.md, Agent Skills, OpenTelemetry’s GenAI conventions and TRACE.
Events, telemetry and the data plane — CloudEvents, xRegistry, OpenTelemetry and its semantic conventions, OTLP, OpenMetrics, xDS and Envoy.
Identity, policy and data rights — SPIFFE, OpenFeature, Cedar and PDPP.
Supply chain and artifacts — SPDX, the three OCI specifications (image, runtime and distribution), in-toto, OSV, SLSA, TUF, Notary, Sigstore, Security Insights, OpenVEX, OpenChain and the Open Component Model.
Financial services — FDC3, CALM, the FINOS Common Domain Model and x402.
Release-path dependencies — the build tooling the specifications are published through (OAI build-infra and SpecRef), because when it breaks, releases stop.
Forty-six of them form the core series I compare week over week; six are newer or narrower and reported alongside. The list grew a lot this week. I added A2A, the AI Catalog and ONNX to the core, then stepped back to ask what else was missing, and added twelve more — including Cedar, because a policy language belongs next to OPA and the work happening in OpenLint. Every one of the fifty-two now has an entry in the catalog. The page is generated from the newsletter’s own registry, so the two can’t drift apart.
The alignment work
Reading repositories is half of it. The other half is showing up, and the page lists what that has looked like lately, each item linked to its public record:
Being in the rooms — the OpenAPI, Overlays and Arazzo calls, the A2A AI Catalog group, MCP working groups and OpenLint’s office hours, written up so others can follow along.
Funding the specifications we depend on — a public list of companies that build on OpenAPI, Arazzo and Overlays and aren’t members of the OpenAPI Initiative.
One front door, not many — mapping every /.well-known/ path on the Well-Known URIs page, following how the agent protocols are converging on the AI Catalog, and asking IANA to register /.well-known/apis.json.
Measuring adoption rather than announcements — like counting the first Personal Agent Protocol files in the wild.
Keeping specifications small and composable — an overlay is a layer, not a diff.
None of this is a standards body or a competing effort. It’s an observer’s job done in public: read what changed, report it honestly — including the weeks I get it wrong — and help the pieces fit together for the people building on top of them.
Come and help
If you maintain one of these specifications, check that I’ve described it correctly. If you depend on one I’m not tracking, tell me which, and why. And if you want the weekly read, the archive is here — it goes out every Monday.
https://apievangelist.com/2026/10/26/the-specification-layer-now-has-a-home/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-specification-layer-now-has-a-home.png
#specificationlayer #home #catalog #apievangelist #every #slsa #agents #open #openresource #overlays
#rss #feeds #linksharing #qwibbit

2026-10-27 02:52:02 GMT

Shipping: The Shape Of The Answer
Last week I wrote about DeepInfer and the shape of the answer, and how batch-invariant inference, deterministic sampling and schema-constrained outputs move the hard problem from “get valid JSON” to “agree on the shape.” I said a shipment exception could come back as the carrier’s own status codes. So I went and looked at what shipping actually has written down.
The answer this industry needs
Shipping runs on unstructured inputs that have to become structured events. An exception email from a carrier saying a delivery was attempted and nobody was home. A scanned bill of lading that has to become a booking or a transport document. A forwarded order confirmation that has to become a tracking number attached to the right order. Somebody, or something, reads that and types it into a system that only accepts a fixed set of values.
So the outcomes are concrete. Turn an exception email into a tracking update with a status the tracking API recognizes. Turn a bill of lading into the booking or transport document a carrier’s API expects. Turn a container milestone into an event a visibility platform can store and reconcile against the next one. None of these are “summarize this.” Every one of them is “produce exactly this payload.”
The shape is already written down
Shipping has more of its shapes written down than most industries, and they come from several directions.
On the ocean side, the Digital Container Shipping Association publishes Track and Trace, Booking, the electronic Bill of Lading, Commercial Schedules, Operational Vessel Schedules, Port Call and Arrival Notice standards. Track and Trace describes the container journey as shipment, transport, equipment, IoT and reefer events, and DCSA publishes these as OpenAPI. The APIs.io DCSA standard page and the API Evangelist standards entry both carry it.
Underneath that, GS1 governs the identifiers: the GTIN for products, the GLN for locations, and the SSCC for logistics units like a pallet. If a model is pulling a pallet identifier off a scanned label, the SSCC is already a defined shape. Then there is UN/EDIFACT and X12, the EDI message grammars that most carrier and shipper integrations still actually run on.
And on the parcel side, the shape that matters most in practice is a vocabulary, not a standard. AfterShip’s tracking API settles every carrier’s status into a short list: Pending, InfoReceived, InTransit, OutForDelivery, AttemptFail, Delivered, AvailableForPickup, Exception and Expired. That is an enum. It is exactly what you hand a constrained decoder so an exception email can only come back as one of those nine values.
What the catalog holds
I looked at the two Market cohorts that cover this: shipping, 25 providers, and maritime logistics, 47 providers.
The parcel and freight side scores well at the top, and it isn’t the carriers. SMKlog leads at 86.1 and AfterShip is right behind at 82.6, both exemplar, with AfterShip carrying the cohort’s highest agent readiness at 59.6. Sendcloud is next at 66.4. The carriers whose events everyone is normalizing sit at the bottom: USPS 33.8, FedEx 29.3, UPS 29.0 and DHL 24.4. The aggregators that publish the carriers they reach score roughly three times what the carriers themselves do.
Artifacts follow the same line. In the shipping cohort, 24 of 25 providers have OpenAPI in the catalog, 14 have AsyncAPI, 13 have JSON Schema, 10 have examples, and 3 (Sendcloud, parcelLab and Onfleet) have Arazzo workflows. One honest note: AfterShip’s 71 JSON Schemas and its vocabulary are derived by API Evangelist from its own OpenAPI, not published by AfterShip. SMKlog’s 10 schemas are marked as published by the provider. You can browse all of it under schemas, vocabularies, examples and AsyncAPI.
AfterShip also has the outcome I described above sitting in its contract. Its email parses API takes an email and returns orders with a confidence_score between 0 and 1. That is a parse-this-email-into-a-shape operation that already exists as an API.
The maritime side is thinner. Sofar Ocean leads at 46.7 and Maersk is at 43.0, down from 48.7 on the previous score, both developing. Only 22 of the 47 have OpenAPI in the catalog, 10 have JSON Schema, and none have Arazzo. Maersk is the one provider where I can see the standard in the contract: three of its eight original OpenAPI files reference DCSA, with booking paths under dcsa/bkg/v2/bookings, bill of lading paths under dcsa/ebl/v3/transport-documents, and DCSA Commercial Schedules. That is a carrier publishing the industry shape as its own API.
On the standards page, 5 catalog providers carry DCSA as a tag. GS1 has 0. EDIFACT has 0.
What determinism changes here
Shipping is a reconciliation business. A container has one booking reference, one transport document reference, and a chain of events that have to line up against each other and against an invoice for demurrage and detention weeks later. If a model reads the same exception email twice and returns AttemptFail once and Exception the next time, you now have two histories for one package and a support ticket nobody can explain.
Batch-invariance matters because this is volume work. Tracking updates get parsed in bulk, at peak, next to everything else in the batch. The answer for one shipment can’t depend on what other shipments happened to be in the same batch.
Deterministic sampling matters for the paperwork. A bill of lading carries legal weight, and customs declarations are filed against it. When someone asks why a field was populated the way it was, “run it again and you’ll get the same answer” is the beginning of an audit trail. “It came out differently that time” is not.
And constraint matters because the targets are closed. A DCSA event type is one of a defined set. An SSCC is a fixed-length identifier with a check digit. A tracking status is one of nine values. A regular expression or a schema enum makes it impossible for the model to invent a tenth status or a malformed pallet ID. The receiving system rejects nothing because nothing invalid can be produced.
Where it falls short
The big ocean carriers are mostly not in the catalog in a way a constrained decoder can use. Hapag-Lloyd scores 5.7, MSC 5.4, Ocean Network Express 4.7 and COSCO 3.3, and I can’t find OpenAPI for any of them in the catalog. CMA CGM is at 14.3. The DCSA shape exists, but I can’t point a model at their published version of it.
eBL platforms have the same gap. WaveBL scores 30.6, and the catalog records that it states compliance with the DCSA issuance and surrender specifications, but I can’t find a contract from it in the catalog to constrain against.
GS1 and EDI are the bigger miss. The identifiers and message grammars the whole industry runs on show up as zero tags in the catalog. I did not find GS1 identifiers or EDIFACT/X12 message names in the cohort’s OpenAPI or JSON Schema. That either means the APIs don’t expose them by name, or the catalog isn’t seeing them. Both are worth fixing. And the parcel carriers still publish their own status codes, so the shared vocabulary in practice belongs to the aggregators, not to a standard.
Close
Shipping is better positioned for this than most industries. DCSA wrote the ocean shapes as OpenAPI, GS1 wrote the identifiers decades ago, and the parcel aggregators already boiled carrier chaos down to a handful of statuses. What’s missing is the carriers publishing those shapes as their own contracts, so the constraint a model works against is the carrier’s, not a third party’s guess. The ones that do will be the ones whose exception emails turn into clean events on the first pass, and the same events on the second.
https://apievangelist.com/2026/10/26/shipping-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/shipping-the-shape-of-the-answer.png
#shipping #shape #answer #api #exception #bill #lading #booking #container #shippingassociation
#rss #feeds #linksharing #qwibbit

2026-10-27 02:08:34 GMT

Calculate Sales Tax And File Returns Automatically With Avalara
If you sell into more than one state, or more than one country, you have probably found yourself searching for how to charge the right sales tax on every order, how to know where you even owe it, and how to get the returns filed without a spreadsheet marathon at the end of every period. Most people asking those questions are not looking for an API. They are looking for the problem to go away. Avalara is one of the companies that makes it go away, and it does it through APIs your store, your billing system, your accounting software, or increasingly an AI assistant can call on your behalf.
What Avalara does
In Avalara’s own words, it helps businesses of all sizes get tax compliance right, with cloud-based solutions that work with existing business applications to calculate tax accurately and file returns automatically. You can find them at avalara.com. The important part of that sentence is “work with existing business applications.” Avalara is not another place you go to do your taxes. It is a service that plugs into the places where you already make sales, so the tax is figured out at the moment of the sale, and the record of it is ready when filing time comes.
What you can get done
I map what a provider can do to business capabilities, the plain-language jobs a business needs done, and then to the specific API operations that do each job. Here is what that looks like for Avalara.
Indirect Tax Management
This is the heart of it: knowing where you have an obligation to collect tax and getting the amount right on every transaction. A big piece of that is nexus, the connection to a state or jurisdiction that obligates you to collect its tax. Avalara lets you declare and manage nexus for each of your companies, then uses it when it calculates tax.
GET /api/v2/companies/{companyId}/nexus lists the places you have declared nexus.
POST /api/v2/companies/{companyId}/nexus declares nexus in a new state.
POST /api/v2/companies/{companyId}/nexus/{nexusId}/parameters adds details to a nexus, such as flagging yourself as a remote seller.
GET /api/v2/companies/{companyId}/nexus/{nexusId}/parameters shows the details set on a nexus.
Tax Reporting & Compliance
Calculating tax is half the job. The other half is reporting it. Avalara’s APIs cover listing, reviewing and submitting VAT returns, and preparing 1099 forms for the people and businesses you pay.
GET /returns lists the VAT returns still waiting to be filed.
GET /returns/{returnId} lets you review a return before it goes out.
POST /returns/{returnId}/submit files a finalized VAT return with the tax authority.
POST /forms/1099 creates a 1099 form with a payee’s payment amounts.
Regulatory Compliance Management
This one surprised me in a good way. If you ship regulated goods, like wine sold direct to consumers, there are rules beyond tax about what you can ship, where, and how much. Avalara can check an order against those rules before it ships.
GET /api/v2/companies/{companyCode}/transactions/{transactionCode}/shipment/verify checks whether an order can be shipped direct to the consumer in their state.
PUT /api/v2/companies/{companyCode}/transactions/{transactionCode}/shipment/registerIfCompliant checks compliance and registers the shipment in one step.
DELETE /api/v2/companies/{companyCode}/transactions/{transactionCode}/shipment/registration removes an order from the volume being tracked against shipping limits.
Identity & Access Management
Less exciting, but it matters when more than one person touches your tax setup. You can add team members, see who has access to an account, and remove someone when they leave.
POST /api/v2/accounts/{accountId}/users adds a team member.
GET /api/v2/accounts/{accountId}/users shows who has access.
DELETE /api/v2/accounts/{accountId}/users/{id} removes someone’s access.
Workflows that put it together
A single API call rarely gets a whole job done. A workflow is a recipe of several calls in the right order, written down so software can follow it. Avalara has 12 of them indexed on APIs.io. A few that map directly to things businesses search for:
Calculate and Commit a Transaction: validate the ship-to address, calculate tax on a sale, commit it, then read it back. This is the everyday “charge the right tax at checkout” job.
Estimate Rate Then Quote: get a free estimated rate for an address, then create a full transaction quote there.
Create Company With Nexus: set up a new company and declare its first nexus, then confirm the list.
Classify an Item and Test Its Tax: look up tax codes, register a product with one, then quote tax for it.
Adjust a Committed Transaction: correct a sale that already went through, with a documented replacement.
Ask for it in plain language
More and more of this work is going to be asked for in a sentence, not built into a screen. To help with that I write conversational overlays for each API, which map the kinds of questions a person might ask to the operation that answers them, so an assistant knows which call to make. For Avalara, that includes questions like:
Which states have I declared nexus in?
How do I declare that my company has nexus in a new state?
Which VAT returns are still waiting to be filed?
Can I ship this wine order direct to the consumer in their state?
Can I create a new 1099 form with a payee’s payment amounts?
These are my phrasings, not a record of what people actually ask, but they show how close the API already is to the way a business owner talks. You can see one of them in the Avalara 1099 forms overlay.
Getting started
Avalara offers self-serve signup, and it is a hosted service, meaning you call their endpoints rather than run anything yourself. Start with the AvaTax reference and the tariff classification reference if you sell across borders. Everything I have indexed is on the Avalara profile on APIs.io, including the AvaTax SOAP API, the Tax Content for Retail Configuration API and the Self-Serve Tariff Classification API. If sales tax is the thing keeping you up at night, find out whether the software you already use connects to Avalara before you build anything yourself.
https://apievangelist.com/2026/10/26/calculate-sales-tax-and-file-returns-automatically-with-avalara/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/calculate-sales-tax-and-file-returns-automatically-with-avalara.png
#returnsautomatically #tax #avalara #salestax #get #post #api #file #vat #taxmanagement
#rss #feeds #linksharing #qwibbit

2026-10-27 01:36:20 GMT

Automate Projects, Tasks And Team Goals With Asana
Every growing team hits the same wall. Work arrives from email, forms, support tickets and chat, and someone has to copy it into the project tool by hand, assign it, and remind people about it. So people search for how to create tasks automatically, how to set up a new project the same way every time, or how to keep goals and projects in sync without a weekly status meeting. If your team runs on Asana, the answer to almost all of those is already there in its API, which lets other software, and now AI assistants, do that copying, assigning and updating for you.
What Asana does
Asana is a web and mobile application designed to help teams organize, track, and manage their work. You can find it at asana.com. The Asana API lets other applications reach into that same work: the projects, the tasks inside them, the portfolios that group projects, and the goals the projects are supposed to move. That means the work can be created and updated by the systems where it starts, rather than retyped.
What you can get done
I map each provider to business capabilities, the plain jobs a business needs done, and then to the API operations that do each job.
Project Management
The core of Asana: creating projects, finding them, updating who owns them, and cleaning them up when they are done.
GET /projects lists projects across a workspace or team.
POST /projects creates a new project.
PUT /projects/{project_gid} renames a project or changes its owner.
DELETE /projects/{project_gid} deletes a project you no longer need.
Strategy Execution Management
This is the goals side of Asana, which is how a company connects its quarterly objectives to the work that is supposed to deliver them. If you track OKRs, this is where they live, and the API lets you keep them current from the systems that actually hold the numbers.
GET /goals lists the goals a team has.
POST /goals creates a new goal for a team.
PUT /goals/{goal_gid} changes a goal’s status, owner or due date.
GET /goals/{goal_gid} shows the full record of a goal.
Portfolio Management
Portfolios group related projects so leaders can see a program of work at once. You can build and maintain them through the API, so the portfolio view stays right as projects come and go.
GET /portfolios lists the portfolios you own in a workspace.
POST /portfolios creates a portfolio.
PUT /portfolios/{portfolio_gid} renames a portfolio or changes its color.
Workflows that put it together
A single call is rarely the whole job. A workflow is a recipe of several calls in the right order, written down so software can follow it. Asana has 22 of these indexed on APIs.io, and they read like a list of things teams wish happened on their own:
Bootstrap a Project Board: create a project in a team, add a section, drop in a first task, and open the discussion with a comment. This is the “set up every new client project the same way” job.
Assign and Add Followers to a Task: create a task, assign it to an owner, and add the people who should be notified.
Add an Existing Task to a Project Section: confirm a task exists, move it into a section, and note the move with a comment.
Attach a File to a New Task: create a task and attach a link to the file it is about.
Add a Custom Field to a Project: create a workspace custom field and attach it to a project, so every project tracks the same thing.
Ask for it in plain language
A lot of this work is moving to people asking an assistant in a sentence. I write conversational overlays that map the kinds of questions someone might ask to the operation that answers them, so the assistant knows which call to make. For Asana that includes:
How do I list projects across a workspace or team?
How do I create a new goal for my team?
How do I change a goal’s status, owner or due date?
Which portfolios do I own in a workspace?
How can I rename a project or change its owner?
These are my phrasings, not a record of what people actually ask. Asana has 36 of these overlays on APIs.io; the allocations overlay is one example.
Getting started
Asana is a paid product with self-serve signup, and the API is a hosted service you call. The reference documentation is organized by object, for example attachments and custom fields. Everything I have indexed is on the Asana profile on APIs.io, including the Attachments API, the Custom Fields API and the Events API. Before you hire someone to keep your project board tidy, check whether the tools your work starts in can talk to Asana directly.
https://apievangelist.com/2026/10/26/automate-projects-tasks-and-team-goals-with-asana/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/automate-projects-tasks-and-team-goals-with-asana.png
#asana #projects #goals #team #api #get #portfolios #tasks #work #post
#rss #feeds #linksharing #qwibbit

2026-10-27 01:03:10 GMT

Take Payments, Run Subscriptions And Send Invoices With Stripe
Most people who end up at Stripe did not set out to use an API. They searched for how to accept credit cards on a website, how to charge customers every month, how to send an invoice that someone can pay online, or how to refund an order. Stripe answers all of those, and it does it through APIs that your website, your billing software, the platform you sell on, or an AI assistant can call for you. Understanding what those APIs can do helps you know what to ask of whoever builds or runs your store.
What Stripe does
Stripe describes itself as online payment processing for internet businesses, a suite of payment APIs that powers commerce for online businesses of all sizes. You can find it at stripe.com. Stripe covers a lot of ground, from one-time payments to recurring billing, invoices, tax and even issuing your own cards, so it helps to break it down by the job you are trying to get done.
What you can get done
I map each provider to business capabilities, the plain jobs a business needs done, and then to the API operations that do each job. Stripe maps to 18 capabilities in my index. Here are the ones most businesses come looking for.
Payment Initiation Management
Getting paid starts here. Stripe uses a “payment intent” to represent a payment you are trying to collect, from the moment you start it until the money is captured.
POST /v1/payment_intents starts collecting a payment from a customer.
GET /v1/payment_intents/{intent} checks the status of one payment.
POST /v1/payment_intents/{intent} changes the amount before the customer pays.
GET /v1/payment_intents/search searches payments by status, amount or other details.
Payments & Card Management
What happens after the sale, including refunds, which is one of the most common things a business needs to do and one of the first things customers ask about.
POST /v1/refunds refunds a customer’s payment.
GET /v1/refunds/{refund} checks the status of a refund.
GET /v1/refunds shows all the refunds you have issued.
POST /v1/refunds/{refund}/cancel cancels a refund that is waiting on customer action.
Subscription Lifecycle Management
If you charge every month or every year, this is the job: signing customers up for a plan, checking when they renew, and cancelling when they leave.
POST /v1/subscriptions signs a customer up for a recurring plan.
GET /v1/subscriptions/{subscription_exposed_id} checks a subscription’s status and next renewal.
GET /v1/subscriptions/search finds subscriptions by status or other details.
DELETE /v1/subscriptions/{subscription_exposed_id} cancels a subscription immediately.
Invoicing & Statement Management
For businesses that bill after the work is done, or bill larger customers who want a proper invoice.
POST /v1/invoices creates an invoice for a customer.
GET /v1/invoices lists the invoices you have issued.
GET /v1/invoices/upcoming previews what a customer will be billed on their next invoice.
GET /v1/invoices/search searches invoices by amount, status or other details.
Card Issuance Management
Less well known: Stripe can issue cards, for example to employees or contractors, and let you approve or decline each purchase as it happens.
GET /v1/issuing/authorizations shows every purchase attempt on the cards you have issued.
POST /v1/issuing/authorizations/{authorization}/approve approves a pending purchase in real time.
POST /v1/issuing/authorizations/{authorization}/decline declines a purchase before it goes through.
Workflows that put it together
A single call is rarely the whole job. A workflow is a recipe of several calls in the right order, written down so software can follow it. Stripe has 31 of them indexed on APIs.io. A few of the most practical:
Authorize and Capture Payment: authorize a payment now and capture the funds later, which is how you charge only when an order ships.
Attach Payment Method: save a card to a customer so they do not have to type it again.
Add and Scale Subscription Item: add an item to a subscription, then change its quantity, which is how per-seat pricing works.
Cancel Subscription: confirm a subscription is active, then cancel it.
Calculate and Settle Tax: calculate tax on line items, then record the tax transaction.
Ask for it in plain language
More of this is being asked of assistants in a sentence. I write conversational overlays that map the kinds of questions someone might ask to the operation that answers them. For Stripe that includes:
How do I refund a customer’s payment?
How do I sign a customer up for a recurring plan?
How do I check a subscription’s status and next renewal?
How do I preview what a customer will be billed on their next invoice?
How do I approve a pending purchase on one of my issued cards in real time?
These are my phrasings, not a record of what people actually ask. Stripe has 71 of these overlays on APIs.io, and the account overlay is a good place to see the shape of one.
Getting started
Stripe is paid, with a free trial and self-serve signup, and it is a hosted service you call. The reference starts with accounts, balance and charges. Everything I have indexed is on the Stripe profile on APIs.io, including the Checkout API, the Charges API and the Balance API. If you are choosing a store builder or billing tool, ask whether it runs on Stripe, because that tells you most of what you will be able to automate later.
https://apievangelist.com/2026/10/26/take-payments-run-subscriptions-and-send-invoices-with-stripe/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/take-payments-run-subscriptions-and-send-invoices-with-stripe.png
#rss #feeds #linksharing #qwibbit

2026-10-27 00:29:09 GMT

Create, Track And Report On Issues Automatically With Jira
If your team lives in Jira, you know how much time goes into getting things into it and keeping them current. Bug reports come in from a support form, incidents from a monitoring tool, vulnerabilities from a security scanner, and someone has to turn each one into an issue, check whether it is a duplicate, and update it when something ships. People search for how to create Jira issues automatically, how to stop duplicate tickets, or how to see deployments on the issue they fixed. All of that is possible through Jira’s APIs, which let the tools where work starts talk to Jira directly, and increasingly let an AI assistant do it for you.
What Jira does
Jira is Atlassian’s project management and issue tracking platform, and its APIs cover the core platform, Jira Service Management and Jira Align. You can find it at atlassian.com/software/jira. What makes Jira’s APIs interesting is not only creating and editing issues. A big part of what they offer is a set of doors for other tools, like deployment pipelines, incident tools and security scanners, to report what they know straight onto the issues it relates to.
What you can get done
I map each provider to business capabilities, the plain jobs a business needs done, and then to the API operations that do each job. Jira maps to 8 capabilities in my index. Here are the ones teams most often need.
Incident Response Management
When something breaks in production, the incident and the review that follows belong next to the work that fixes it. Jira lets an operations tool push incident and review data in, so the people fixing it see it in one place.
POST /rest/operations/1.0/bulk pushes incident and review data into Jira.
GET /rest/operations/1.0/linkedWorkspaces shows which operations workspaces are linked to your Jira site.
DELETE /rest/operations/1.0/bulkByProperties bulk deletes incident data matching certain properties.
Deployment Orchestration
“Did this fix ship yet?” is one of the most asked questions in any software team. Jira lets your build and release pipeline report deployments so they show on the issues they include, and can tell you whether a deployment is gated.
POST /rest/deployments/0.1/bulk reports deployments from your pipeline so they show on Jira issues.
GET /rest/deployments/0.1/pipelines/{pipelineId}/environments/{environmentId}/deployments/{deploymentSequenceNumber}/gating-status tells you whether a deployment is gated or allowed to proceed.
Vulnerability Management
Security findings are only useful if they become work someone owns. Jira lets a security tool push vulnerabilities in, so they can be triaged like any other issue.
POST /rest/security/1.0/bulk pushes vulnerabilities from your security tool into Jira.
GET /rest/security/1.0/linkedWorkspaces shows which security workspaces are linked to your Jira site.
Webhook & Event Subscription Management
The other direction: having Jira tell your software when something changes, so you do not have to keep checking.
POST /rest/api/3/webhook subscribes your app to Jira issue events.
GET /rest/api/3/webhook/failed shows deliveries to your app that failed after all retries.
PUT /rest/api/3/webhook/refresh keeps webhooks your app registered from expiring.
Workflows that put it together
A single call is rarely the whole job. A workflow is a recipe of several calls in the right order, written down so software can follow it. Jira has 10 of them indexed on APIs.io, and they cover the everyday issue work:
Deduplicate Issue Intake: search for an existing issue and either comment on the duplicate or create a new one. This is the answer to “how do I stop duplicate tickets.”
Create an Issue and Read It Back: look up the project details, create an issue, then confirm what was stored.
Edit an Issue and Verify the Change: change fields and labels, then re-read to make sure it took.
Read an Issue Comment Thread and Reply: read the conversation on an issue, oldest first, then add a reply.
Run a JQL Report and Drill Into a Result: run a search and drill into the first matching issue and its comments.
Ask for it in plain language
More of this is going to be asked of an assistant in a sentence. I write conversational overlays that map the kinds of questions someone might ask to the operation that answers them. For Jira that includes:
How do I report deployments from my CI/CD pipeline so they show on Jira issues?
Is my deployment currently gated or allowed to proceed?
How does my security tool push vulnerabilities into Jira?
Which webhook deliveries to my app failed after all retries?
How do I subscribe my app to Jira issue events with a webhook?
These are my phrasings, not a record of what people actually ask. Jira has 122 of these overlays on APIs.io; the announcement banner overlay is one example.
Getting started
Jira is freemium with self-serve signup, and the APIs are a hosted service you call. Start with the platform REST API introduction and the authentication guide. Everything I have indexed is on the Jira profile on APIs.io, including the Jira Cloud Platform REST API v2, the Jira Service Management Operations REST API and the Jira Align REST API. Before anyone copies another ticket by hand, check whether the tool it came from can send it to Jira itself.
https://apievangelist.com/2026/10/26/create-track-and-report-on-issues-automatically-with-jira/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/create-track-and-report-on-issues-automatically-with-jira.png
#jira #issuesautomatically #security #management #incident #get #post #jiraalign #jiraservice #create
#rss #feeds #linksharing #qwibbit

2026-10-26 23:56:30 GMT

Track Errors, Releases And Cron Jobs In Your Software With Sentry
If you run a website or an app, the worst way to find out it is broken is from a customer. So people search for how to get alerted when their site throws errors, how to know which release introduced a bug, or how to find out when a scheduled job quietly stopped running. Sentry is built for exactly those questions, and its API means your other tools, and now AI assistants, can ask Sentry what is going wrong and act on the answer.
What Sentry does
Sentry describes itself as an open-source error tracking and performance monitoring platform that helps developers identify, triage, and resolve issues in their applications in real time. You can find it at sentry.io. Its API covers issues and events, releases and deploys, alerting, dashboards, session replays, cron and uptime monitors, and user provisioning. Sentry also says it runs its own remote MCP server, which is how an AI assistant connects to a service like this.
What you can get done
I map each provider to business capabilities, the plain jobs a business needs done, and then to the API operations that do each job. Sentry maps to 7 capabilities in my index. Here are the ones most teams need.
Observability Management
This is the core: seeing the errors and events your software produces in the wild, grouped into issues, with the detail you need to fix them.
GET /projects/{organization_id_or_slug}/{project_id_or_slug}/events/ lists recent error events in a project.
GET /issues/{issue_id}/events/ shows the individual events that make up an issue.
GET /issues/{issue_id}/events/{event_id}/ pulls one event through its issue.
GET /projects/{organization_id_or_slug}/{project_id_or_slug}/events/{event_id}/source-map-debug/ helps explain why a JavaScript stack trace is still unreadable.
Software Quality Engineering
Beyond single errors, the bigger question is whether things are getting better or worse, and which issues to tackle first.
GET /organizations/{organization_id_or_slug}/issues/ finds unresolved issues across all your projects.
PUT /organizations/{organization_id_or_slug}/issues/ resolves many issues across projects at once.
GET /organizations/{organization_id_or_slug}/prevent/test-results/ shows which tests failed recently.
GET /organizations/{organization_id_or_slug}/prevent/test-results/metrics/ tells you how flaky your test suite is overall.
Release Engineering Management
Knowing which version of your software is running, and which one an error started in, is how you go from “something broke” to “this change broke it.”
POST /organizations/{organization_id_or_slug}/releases/ tells Sentry about a new version you are shipping.
GET /organizations/{organization_id_or_slug}/releases/ lists the releases in your organization.
PUT /organizations/{organization_id_or_slug}/releases/{version}/ marks a release as released with a date.
Tenant Identity Federation
For larger teams, people should get Sentry access when they join and lose it when they leave, automatically, from the identity system the company already uses.
POST /organizations/{organization_id_or_slug}/scim/v2/Users provisions a new user from your identity provider.
PATCH /organizations/{organization_id_or_slug}/scim/v2/Users/{scim_user_id} deactivates a user without deleting them.
DELETE /organizations/{organization_id_or_slug}/scim/v2/Users/{scim_user_id} removes someone when they are offboarded.
Workflows that put it together
A single call is rarely the whole job. A workflow is a recipe of several calls in the right order, written down so software can follow it. Sentry has 12 of them indexed on APIs.io:
Create a Cron Monitor and Verify Check-ins: watch a scheduled job and confirm it is checking in, which answers “how do I know when my nightly job stopped running.”
Create a Metric Alert Rule: set up an alert and confirm it is active.
Cut a Release and Record a Deploy: create a release, record a deploy to an environment, and list its deploys.
Capture User Feedback for an Event: attach what a user told you to the error they hit.
Create a Team and Add a Member: set up a team and put the right people on it.
Ask for it in plain language
More of this is going to be asked of an assistant in a sentence. I write conversational overlays that map the kinds of questions someone might ask to the operation that answers them. For Sentry that includes:
How do I find unresolved issues across all my projects?
Which error events came into a project recently?
How do I tell Sentry about a new version I’m shipping?
How flaky is my test suite overall?
How does offboarding in our IdP remove someone from Sentry?
These are my phrasings, not a record of what people actually ask. Sentry has 43 of these overlays on APIs.io; the alerts overlay is one example.
Getting started
Sentry is freemium with self-serve signup, and the API is a hosted service you call. Start with the API documentation, the events reference and the authentication guide. Everything I have indexed is on the Sentry profile on APIs.io, including the Alerts API, the Check-Ins API and the Commits API. If customers are the ones telling you your site is down, that is the first thing to change.
https://apievangelist.com/2026/10/26/track-errors-releases-and-cron-jobs-in-your-software-with-sentry/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/track-errors-releases-and-cron-jobs-in-your-software-with-sentry.png
#sentry #get #software #errors #jobs #api #management #engineering
#rss #feeds #linksharing #qwibbit

2026-10-23 19:56:57 GMT

Gateways Count Every Token And Charge For Almost None Of Them
Last month I came out of Josh Twist’s talk on MCP monetization in Stockholm arguing that API monetization is falling flat, and maybe it is the word. AI puts a cost on both sides of every call, so we should stop talking about monetization and start talking about API economics. I wanted to see whether the infrastructure agrees. The place an API’s economics actually get enforced is the gateway, so I went and read the gateways.
Twelve of them: Zuplo, Azure API Management, Apigee, MuleSoft, Kong, Apache APISIX, Traefik, Tyk, Gravitee, WSO2, Envoy and Amazon API Gateway. Eleven publish a catalog of the behaviors you can attach to an API at runtime. They call them policies, plugins, middleware or filters, but they mean the same thing. Amazon is the one without a catalog. I read every entry, 884 in all, and sorted them into eighteen areas so they could be compared side by side.
Area by gateway
Here is the whole thing. Click any cell to see the policies behind the number, click an area or a gateway to see all of it, or filter for a term like token, cost or meter. Start with the ai row, then look at monetization just below it.
Click a cell, an area or a gateway to list its policies. Shading is relative to each gateway's own catalog.
Loading the policy catalogs…
&<>"&match&match&g
https://apievangelist.com/2026/10/23/gateways-count-every-token-and-charge-for-almost-none-of-them/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/gateways-count-every-token-and-charge-for-almost-none-of-them.png
#api #joshtwist #apimanagement #azureapi #apigateway #amazonapi #apacheapisix #click #mcp
#rss #feeds #linksharing #qwibbit

2026-10-23 19:23:38 GMT

API Monetization Is Falling Flat, Maybe It Is The Word
I sat in on Josh Twist’s talk on MCP monetization at the Nordic APIs Summit in Stockholm last week. Zuplo’s framing starts from Marc Benioff’s line about the end of the UI and the birth of “headless SaaS”: a single user can now generate an enormous amount of work against your systems through their swarms of agents, so it is time to make money from all those agents using your data and services. I agree with every word of the problem. And I left the room thinking the same thing I think every time this topic comes up: this is 100 times more important than the attention it gets, and the word we use for it is part of the reason it falls flat.
Fifteen years of calling it monetization
I have been writing about this since the beginning of this blog. In 2011 it was API business models and how to choose the right one. In 2014 it was resource-based versus experience-based pricing. In 2015 I tried to formalize an API monetization framework so I could price the APIs I was bringing online. The archive has close to four hundred posts that mention monetization, and they come in waves. 2011, 2015 and 2017 were the big years. Then it went quiet for half a decade, and it is coming back now because of AI.
Somewhere around 2018 I started calling it something else. API management is the measurement of value exchanged: every call is logged, every caller has a key, and so you can see exactly what value is flowing to whom. Later that year I wrote that venture capital was obscuring the opportunities for value exchange at the API management level, because the vendors were incentivized to sell a platform, not to help you understand your own economics. And this June I made it official in API Value Exchange: the word monetization has always been a barrier in exactly the places where API value matters most. I couldn’t walk into a federal agency and talk about monetizing campsite reservations. The value was real, but the word shut the conversation down.
Why monetization falls flat
I think there are three reasons, and AI makes all three worse.
It sounds like a tax. Monetization tells everyone on the consuming side that the conversation is about extracting money from them. Developers hear paywall. Partners hear renegotiation. Internal teams hear chargeback. The people who most need to understand the value flowing through an API are the ones the word pushes away.
It is one direction. Monetization describes money coming in. But APIs have always been an exchange, and the value goes both ways: data for reach, access for feedback, free tiers for adoption, partner APIs for distribution. Most of the value in most API programs never touches an invoice.
It ignores the cost side. This is the one AI breaks wide open. When a provider served a weather lookup, the marginal cost was close to nothing, and monetization was purely a revenue question. When a provider serves an agent, it may be running model inference on every call, and paying for it. The caller may be an agent that is itself burning tokens to decide what to call next. Every interaction now has a cost on both sides, measured in compute and tokens as much as in requests. You can’t talk only about the revenue line when the cost line moves with every call.
What I think we should call it
API value exchange was the right correction, and I still use it. It names the two-way nature of the thing. But I think AI pushes us one step further, to API economics.
Economics is the word for a system where value, cost and incentive all move at once, between many parties, at scale. That is what an API program looks like with agents in it. It covers the revenue, which monetization was always about. It covers the exchange, which value exchange was about. And it covers the part neither word did: unit costs, who pays for the inference, how pricing shapes agent behavior, and whether the whole thing is sustainable for both the provider and the consumer.
It also matches the artifacts that already exist. The pieces of API economics are all things a provider can publish:
Plans that say what access costs and what it includes. More than 10,500 providers in the APIs.io catalog have a plans artifact.
Rate limits that say where the ceiling is. Nearly 9,800 providers document them.
FinOps mappings that say what the unit is and what it costs. About 6,600 providers have one, and it is the thinnest of the three.
Per-call and per-tool pricing that an agent can read before it calls. Pipedrive put a price on every tool call, but when I asked 616 MCP servers, only five put a price in a field a machine can read.
Payment protocols like x402 and the Machine Payments Protocol, which let an agent pay without a person. I set a baseline for that last week, and it is small.
That is the gap Josh’s talk points at from the vendor side. The agents are already generating the work. What most providers haven’t done is publish the economics of their API in a form the agent, or the agent’s owner, can read.
Why it matters more than ever
When the consumer was a developer, the economics could live in a pricing page, a sales conversation and a contract. A human read them once, at the start, and then the integration ran. An agent doesn’t read your pricing page, and it doesn’t negotiate. It decides what to call based on what it can see, every time, at a volume no human integration ever produced. If the cost, the limit and the value of a call are not written down where it can read them, the agent will either ignore them or route around you to someone who did write them down.
There is really only API consumption, and consumption has economics whether you name them or not. Monetization was the narrowest way to talk about that. Value exchange was better. I think economics is where this has to go, because that is the conversation leadership is actually having right now: what does this AI-driven consumption cost, what is it worth, and who pays. If we in the API space keep calling it monetization, we will keep getting the room’s attention for five minutes. If we call it what it is, we might get the budget.
I’m not attached to the word. I’m attached to the conversation finally happening. If you have a better name, I want to hear it.
https://apievangelist.com/2026/10/23/api-monetization-is-falling-flat-maybe-it-is-the-word/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/api-monetization-is-falling-flat-maybe-it-is-the-word.png
#api #monetization #word #value #flat #apissummit #nordicapis #joshtwist #marcbenioff #valueexchange
#rss #feeds #linksharing #qwibbit

2026-10-23 14:45:57 GMT

Open Responses Gets A Neutral Home, And A Baseline
OpenAI has donated Open Responses, its specification for a common LLM API, to the Agentic AI Foundation, the Linux Foundation home that already holds MCP, A2A and AGENTS.md. The New Stack has the story. Open Responses joins alongside Anthropic’s Agent Skills, OpenSandbox, and Hugging Face’s environment framework. The idea is simple: every LLM provider now offers the same building blocks, messages, tool calls, streaming and multimodal inputs, and every provider encodes them differently. Open Responses wants one schema for those primitives, based on the OpenAI Responses API, so you describe a request once and run it across providers.
I think this is a good move, and a neutral home is the right one. A specification that one vendor owns is a product. A specification under a foundation, with maintainers from several companies and a technical charter, has a chance to become a standard. The project page already has the three things I look for: a specification, an OpenAPI reference for the full surface, and acceptance tests you can run against your own API. That last one matters more than anything else on the page.
Where it starts from
I can say something about the starting line, because we have been measuring exactly this market. Last week I wrote about six standards nobody ratified, and two of them are this fight. The API Commons profiles grade every operation by the share of a publishing cohort that declares it in its own OpenAPI. The profiles were last measured on September 13, so treat these as a dated baseline.
The OpenAI interface. 211 providers in the catalog say they are OpenAI-compatible, and 120 of them publish an OpenAPI we could read. Of those 120:
Operation
Providers declaring it
Tier
POST /chat/completions
105, 87.5%
core
GET /models
86, 71.7%
core
POST /embeddings
39, 32.5%
extended
POST /responses
26, 21.7%
extended
GET /responses/{response_id}
9, 7.5%
extended
Two operations out of 338 make the core of what “OpenAI-compatible” means in practice, and neither of them is Responses. Chat Completions is the de facto standard. Responses is declared by about one in five of the providers who claim compatibility, and the rest of its surface, deleting, cancelling, compacting and listing input items, is in single digits.
The Anthropic Messages dialect. 34 providers claim Anthropic compatibility, and 29 publish an OpenAPI with an operation unique to it. Its core is POST /v1/messages, declared by 20 of them, and GET /v1/models, by 21. The New Stack makes the same point I would: the Messages API has left its own mark, largely through Claude Code, and a growing list of model providers now expose Anthropic-compatible endpoints alongside OpenAI ones.
So the market Open Responses is walking into has two dialects that people actually copy, and the one it is based on is not the one most people copied. That is the job.
What would make it a standard
The support list in the announcement is long: AWS Bedrock, Databricks, Ollama, LM Studio, Hugging Face, Nvidia, OpenRouter, Red Hat, Vercel, vLLM and others. Saying you support a specification is the start. What I’d watch for is the same thing I measure everywhere else.
Declaration in the contract. A provider that supports Open Responses should say so in its own OpenAPI, with the Responses operations in it. Today 26 of 120 compatible providers do that for the Responses endpoint. That is the number I want to see move.
Acceptance tests that get run. The project ships them. A provider that publishes its results, and an index of who passes, would turn “compatible” from a marketing word into a fact. That has been missing from every one of these de facto standards.
A core small enough to agree on. The OpenAI interface has a core of two operations because that’s all the market agrees on. Open Responses defines items, streaming events and tool use as its atoms. The narrower the core everyone implements, the faster it spreads.
Room for the other dialect. If Open Responses maps cleanly to what Messages-compatible providers already do, it becomes a bridge. If it doesn’t, we keep two camps and an adapter in the middle, which is where lock-in lives. I wrote about exactly that split with decision models: the questions converged and the URL didn’t.
Why this matters past the model call
Every agent framework, gateway and router I profile spends real effort translating between these dialects. A shared, neutrally governed shape for the model call means that effort can go into the parts that are actually different: the tools, the data and the business on the other side of the call. That is the part of the agent stack I care most about, and it gets easier when the model call underneath it is boring.
Open Responses belongs in the API Evangelist standards catalog and in the profiles we re-measure, and the next measurement of the OpenAI and Anthropic interfaces should carry a Responses column. Then we’ll know whether a neutral home moved the numbers.
https://apievangelist.com/2026/10/23/open-responses-gets-a-neutral-home-and-a-baseline/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/open-responses-gets-a-neutral-home-and-a-baseline.png
#openresponses #neutralhome #baseline #api #providers #post #newstack #get #linuxfoundation #messages
#rss #feeds #linksharing #qwibbit

2026-10-23 14:13:49 GMT

If You Depend On OpenAPI Please Become a Member
I’m going to ask for money, so I’ll get straight to it. If your business depends on OpenAPI, please become a member of the OpenAPI Initiative. If you were a member and let it lapse, please come back.
It is more than one specification
When people hear “OpenAPI” they think of the one document that describes an HTTP API. That is still the heart of it — OpenAPI 3.2 shipped last year — but the OpenAPI Initiative now maintains three specifications, and the other two are where a lot of the industry’s next work lives:
Arazzo describes multi-step workflows across APIs — the sequences an integration, or an agent, actually has to perform. Arazzo 1.1 shipped in May, and SOAP, Protobuf, GraphQL and human-in-the-loop support are being worked on now.
Overlays let you change an OpenAPI description without forking it — the way platform teams, documentation tools and catalogs like mine adapt descriptions they don’t own. Overlay 1.2 shipped in September.
And beneath all three sits shared publishing and build infrastructure, special interest groups for security and API lifecycle, and the schemas every editor, linter and generator validates against.
All of that is maintained by a small group of people, most of them volunteering hours their employers may or may not know about. I sit in on the calls most weeks and write up what I learn. The work is careful, slow in the right ways, and badly under-resourced for how much of the API economy runs on top of it.
Who is paying for it today
The Linux Foundation publishes the membership. Today the OpenAPI Initiative has 32 active members: 21 companies and 11 academic or non-profit organizations. Thank you to every one of them:
Google, Microsoft, IBM, SAP, eBay, Bloomberg, Kong, SmartBear, Redocly, Scalar, Bump.sh, Tyk, 42Crunch, Jentic, Platformatic, IFS, AVAP, Briscola, Getting APIs to Work, LFOD and Level 250, plus the UK Government, NHSX, the OpenTravel Alliance and eight more academic and non-profit members.
Now look at who isn’t on that list. The same records show 68 companies that were members and aren’t today — and API Evangelist is one of them, so I’m not asking anyone to do something I’m exempting myself from. And a much longer list of companies have never been members at all, including many whose products only work because OpenAPI does.
The list I’m working from
I’m going to work through these companies one by one, and I’m publishing the list so it’s out in the open and so you can help. It comes from the Linux Foundation’s member records, my own survey of the tools that read and write OpenAPI, and the APIs.io catalog, which holds thousands of OpenAPI descriptions. I’ll update this post as companies join or come back.
If OpenAPI is your product’s input format
These companies sell products that read OpenAPI, generate from it, or are built around it. Every new version of the specification is work on their roadmap, and every one of them benefits directly from the specification being well maintained. None of them has been a member:
Stainless, Fern, Mintlify, liblab, APIMatic, Zuplo, Gravitee, Solo.io, Axway, Boomi, Sideko, Apidog, Composio, Pipedream, Zapier, Toolhouse and Smithery.
And the two largest consumers of OpenAPI I can find outside the membership: Amazon Web Services, whose API Gateway imports and exports it, and Cloudflare, whose products read it and whose own OpenAPI estate is the largest of any non-member in my catalog. OpenAI and Anthropic belong here too — so much of the API world becomes an agent’s tools by way of an OpenAPI description.
If you were with us before
These companies were members and aren’t today. The decision was made once; I’d love to understand what changed, and I’d love even more to see you back:
Postman, ReadMe, Stoplight, Speakeasy, GitBook, RapidAPI, Salesforce and MuleSoft, Atlassian, Adobe, Cisco, Red Hat, PayPal, Intuit, Capital One, SWIFT, Samsung, Vonage, Dynatrace, Checkly, WSO2, Software AG, Apideck, Ably, Treblle, WireMock, Karate Labs, Kubeshop and The Guild.
If you publish OpenAPI at scale
These are some of the strongest API programs in my catalog. They publish large OpenAPI descriptions for their own developers, which means their developer experience depends on the specification and on the tooling built on it. None has been a member:
Twilio, HubSpot, Shopify, Harness, Telnyx, Confluent, Infobip, Oracle, Optimizely, Elastic, Okta, Datadog, MongoDB, BigCommerce, Sinch, Merge and Svix.
What I’m asking
If your company is on one of those lists, or should be, become a member. The membership page lists who is in today, and the Linux Foundation’s join form takes it from there. Membership is priced by company size, and it is a small line in any budget that includes an API program.
If you can’t make that call yourself, forward this to someone who can. If you have engineers who care about any of the three specifications, send them to the weekly calls, too — the community calendar is open to everyone, and contributions of time matter as much as money.
And if you think I have your company wrong — you’re a member under a parent company I missed, or you support the work in another way — tell me, and I’ll fix the list. I’d much rather be corrected into a shorter list than keep a long one.
I’m not trying to shame anyone. Most companies that depend on OpenAPI have simply never been asked. Consider this the ask. The specifications that describe the API economy deserve to be paid for by the API economy, and the companies that benefit most are the ones best placed to do it.
https://apievangelist.com/2026/10/23/if-you-depend-on-openapi-please-become-a-member/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/if-you-depend-on-openapi-please-become-a-member.png
#pleasebecome #openapi #openapiinitiative #member #work #api #linuxfoundation #every #may #gettingapis
#rss #feeds #linksharing #qwibbit

2026-10-23 13:36:24 GMT

Insurance: The Shape Of The Answer Is Behind A Login
Earlier this week I wrote about DeepInfer and the shape of the answer, and how batch-invariant inference, deterministic sampling and schema-constrained output move the hard problem from “get valid JSON” to “agree on the shape.” Insurance is the industry where that argument gets interesting, because the shape has been agreed on for fifty years. You just can’t easily see it from outside.
The answer this industry needs
Insurance runs on unstructured input turning into structured records. An adjuster’s notes from a site visit. A customer email that says a pipe burst on Saturday. A phone call that becomes a first notice of loss. A broker’s submission packet with loss runs and a schedule of locations. Every one of those has to become something a core system will accept.
The outcomes are concrete. Turn a first notice of loss into a valid claim, with a claim type, the policy it attaches to, the coverage it falls under, and an initial reserve. Turn a submission into a quote request with the right lines of business, limits and insured parties. Turn a claimant’s email into a party record and a contact that matches the one already on file. None of these is a yes, no or score. Each is a specific object with specific fields and specific code lists, and the system on the other side rejects anything else.
The shape is already written down
ACORD has been the insurance industry’s data standards body since the 1970s. Its data standards page lists the families: Property & Casualty XML and AL3, Life & Annuity XML, Global Reinsurance & Large Commercial XML and JSON covering claims, placing, and accounting and settlement, and the Next-Generation Digital Standards, which ACORD describes as “granular, transaction-centric Standards for APIs, microservices, IoT, and more.”
NGDS is the one that matters for this conversation. The NGDS page lists a v1-13-0 final release from May 2026 and a v1-14-0 candidate release this month, plus user stories broken out by capability, including Claims, Sales, Customer Service and Agreement Administration, and an API glossary. That is exactly the material a constrained decoder needs: the objects, the code lists, and the transactions they move through.
Here is the honest part. ACORD says on the same page that it offers its standards, implementation guides and construction tools “to ACORD members,” and that you need the right membership or participation program and an acord.org account to get the files. The landing pages are public. The schemas are not. The APIs.io profile for ACORD puts it plainly: the machine-readable schema exists as XML Schema, and it is members only. ACORD is also moving toward agents. In May its Solutions Group announced MCP-enabled architecture across products including ADEPT and ACORD Transcriber. But that is a product, not an open shape.
The APIs.io standards page lists six insurance standards. ACORD is carried as a tag by 17 catalog providers, CIECA by 3, CSIO by 4, and CLIEDIS, IVANS and the Market Reform Contract by none yet. The ACORD profile is careful to say a tag is the provider’s own statement, not a verified implementation.
What the catalog holds
The insurance industry page counts 704 providers and 2,291 APIs. The insurance market cohort, built from core-system marketplaces and carrier coverage, has 25 members. Three of them score in the strong band:
Canopy Connect at 66.4, agent readiness 40.5.
1Fort at 64.5, agent readiness 29.9.
Guidewire at 63.6, agent readiness 40.5.
Aclaimant follows at 54.5, also strong. Everyone else in the cohort is developing or thin, down to Coalition at 33.3. The best agent readiness score in the cohort belongs to Socotra at 52.3, and it is the only member above 50. The gap between “has an API” and “an agent can safely act on it” is wide across the whole market.
On artifacts, 24 of the 25 cohort members have OpenAPI in the catalog. Far fewer have the pieces a constrained decoder actually wants. Seven have a JSON Schema folder, five have a vocabulary, and seven have examples. Root stands out with 85 JSON Schema files and 239 examples, while scoring thin overall at 37.5, which is a reminder that the shapes and the score measure different things. Duck Creek has 24 schema files and AmTrust has 7.
The ACORD repo itself is the uncomfortable example. ACORD’s catalog profile has claims, policy, party and underwriting OpenAPI, 16 JSON Schemas, 16 JSON Structure files and 16 examples, including an NGDS claim request and an underwriting submission. I have to be clear: those OpenAPI files are API Evangelist’s work, marked generated with an example.com server, and the claim request schema has six fields, policyId, lossDate, lossDescription, lossLocation, claimant and estimatedLossAmount. It is a placeholder for the shape, not the shape. The real one is behind ACORD’s member login.
The most interesting thing I found is in 1Fort’s own harvested OpenAPI. It has operations that stream the blank Acroform PDF of an ACORD form linked to a coverage, and a setting described as “use ACORD form tables to generate questions instead of LLM.” That is a provider choosing the standard over the model when it needs the answer to be right. That is the whole argument of this series in one boolean.
What determinism changes here
Insurance is regulated, audited and reconciled, and claims are litigated. If a model reads a first notice of loss and sets a reserve, someone will eventually ask why that number, and whether you would get the same number again. With sampling that varies run to run, and results that change depending on what else was in the batch, the honest answer is “probably not.” That isn’t acceptable for a reserve that hits financial statements, or for a coverage determination a regulator or a court may review.
Batch-invariant, deterministic inference means the same FNOL text produces the same claim payload on reprocessing, during an audit, or when a market conduct examiner asks for it. Constrained output means the claim type comes from the code list and the coverage is one the policy actually carries, not a plausible string. Volume matters too. After a catastrophe, carriers take in claims by the thousands in days, and that is exactly when batches are full and when a result that shifts with the batch would do the most damage.
The pairing ACORD already has, an object model plus code lists plus transactions, maps directly onto a JSON Schema for the payload, a vocabulary for the enums, and an Arazzo-style sequence for FNOL to claim to reserve. The agentic access layer is where you say that setting a reserve needs a human to approve it.
Where it falls short
The standard exists. The open, machine-readable form of it doesn’t, at least not anywhere I can reach without a membership. So the industry with one of the oldest agreed shapes is set up to repeat the decision-model problem anyway. Every insurtech and every carrier team writes its own claim schema, or prompts a model with a description of ACORD in prose, and hopes.
The public APIs are thin. Of the 17 providers that tag themselves with ACORD, only two, Whitespace at 45.7 and PPL at 45.3, score above 40, and most are emerging or minimal. I can’t find a provider in the catalog publishing JSON Schema that is plainly ACORD’s object model. Where the ACORD names show up in public, they show up as PDFs of forms.
Guidewire, Duck Creek and Socotra each publish their own APIs and their own object models. They are real shapes, but each is one company’s.
Close
Insurance did the boring work decades ago. What it hasn’t done is put that work where a constrained decoder, or anyone outside a membership program, can pick it up. If ACORD published NGDS as open JSON Schema and vocabularies, even just the claim, coverage, party and submission core, deterministic inference could make “turn this email into a valid claim” a solved problem across the market instead of a separate build at every carrier. Until then, the shape of the answer in insurance is real, and it is behind a login.
https://apievangelist.com/2026/10/23/insurance-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/insurance-the-shape-of-the-answer.png
#shape #acord #answer #insurance #standards #xml #acordtranscriber #json #turn #annuityxml
#rss #feeds #linksharing #qwibbit

2026-10-22 21:32:00 GMT

We Did Not Skip Hypermedia, We Moved It Out Of The Response
Earlier today I wrote that we had the agent protocol in 2008 and left it on the table. Leonard Richardson laid out a heuristic at QCon that topped out at hypermedia, meaning links that tell you where the resources are and forms that tell you what you can do to them. Most providers stopped one step short, and now we are building agents on top of what they shipped. After I published it, the obvious question came back at me: if we skipped hypermedia, what are OpenAPI, Arazzo, Overlays, MCP, and A2A? I think the more honest answer is that we didn’t skip hypermedia. We took it out of the response and rebuilt it as a stack of documents sitting next to the API.
Where each piece went
Richardson’s model had three web technologies doing the work: URIs, HTTP, and hypermedia. Over fifteen years we kept the first two and slowly redistributed the third across specifications.
OpenAPI is the second step, written down. It keeps the URIs and the HTTP methods intact, so an agent reading it still knows that a GET is safe. The forms Richardson talked about live in its request bodies and JSON Schema. It even has a links object, which says the id in this response feeds that operation over there. That is hypermedia described at design time, and almost nobody fills it in. That little corner of the spec tells you how far the community was willing to go back toward hypermedia, and how far developers were willing to follow.
Arazzo is the next step, written down. Richardson said the response should tell the client what it can do next. Arazzo describes the next step in a separate document instead: this call, then that one, with outputs feeding inputs and success criteria deciding which way to go. It’s the application state machine written out ahead of time. For an agent, that can be better than hypermedia, because it sees the whole workflow before the first call instead of discovering it one response at a time.
Overlays are Richardson’s third closing principle. He said to describe the differences between complex systems in a standard way so people can learn them quickly. Overlays let you add meaning to a contract without touching the source: what an operation is for, when to use it, what to be careful about, how a person would ask for it. That’s how you make an API you don’t own, or can’t change, readable to an agent. It’s how we have been adding conversational phrasing to operations across the catalog.
MCP is the client interface, and it’s mixed. Tools are called over JSON-RPC through a single endpoint, which is the bottom of Richardson’s heuristic. Resources have URIs and URI templates, which is the first step and the part of MCP that most follows the web. Tool annotations like readOnlyHint and idempotentHint rebuild what HTTP methods already said. What MCP gets right is listing its capabilities at runtime. What it mostly lacks is results that point to what to do next.
A2A is the same move between agents. The agent card at a well-known URI is a pure first-step idea: an addressable description you can find. Tasks have state and move through a lifecycle, which is application state again, but the protocol reports that state rather than letting a client navigate it through links. It’s a JSON-RPC envelope with a discovery document beside it, the same shape as MCP.
Put it together and the old pieces are all still there. Links became Arazzo, forms became OpenAPI and JSON Schema, the media type became the contract, the meaning layer became Overlays, and discovery became well-known paths and agent cards. We didn’t abandon hypermedia. We unbundled it.
In the response or beside it doesn’t matter. When it’s read does.
Richardson’s actual complaint was about coupling. Amazon S3 made you learn its rules from the documentation and bake them into your client, so when the service changed, your client broke. The problem wasn’t documentation. It was knowledge frozen into a client at build time.
Seen that way, there are three ways to consume the same spec stack:
Generated at build time. Take the OpenAPI, push the button, ship an SDK. The knowledge is frozen the day you compiled it. This is the coupling Richardson warned about, whatever the spec is called.
Read at runtime. An agent fetches the OpenAPI, the Arazzo workflow, and the overlays when it needs them, and reasons over the current versions. That’s much closer to hypermedia than most of us have admitted. The discovery happens when it’s needed, not ahead of time.
Live in the response. Links and actions returned with each representation, reflecting the state of this specific resource right now.
Agents make the second option practical in a way it never was for human developers. A person was never going to re-read your OpenAPI before every call. An agent will.
The gap the specs can’t close
There’s one thing the documents can’t do. An Arazzo workflow can describe every path that’s possible in general. It can’t tell an agent that this particular order already shipped, so the cancel action is gone. A hypermedia response just leaves the cancel form out. That’s per-response state: what’s possible right now, for this resource, for this caller. It’s the one piece of Richardson’s level three we never moved out of the response, because it can’t live anywhere else.
That’s also where agents get hurt. An agent with a perfect map and no view of current state will try the operation the map says exists, and then it has to make sense of the error. Multiply that by every agent and every call, and it isn’t a purity argument anymore. It costs money in tokens, retries, and wrong actions.
What I’d tell a provider
Use the stack for the map and the response for the state:
OpenAPI for the contract, with the HTTP semantics left intact rather than flattened into a tool list.
Arazzo for the workflows people actually run, so an agent sees the whole path before it starts.
Overlays for the agent-facing meaning layer, kept separate from the source contract so it can evolve on its own.
MCP and A2A for the agent interface. Keep pointing them back at the URIs and the contract, and don’t let them become a second copy of your API that drifts.
Links and available actions in the response for the state, even if it’s just a next, a self, and the operations currently allowed on this resource.
Richardson ended his talk saying these are different ways of looking at the same thing. I think that’s true of this stack too. The specifications are level three split into separate documents. The only part that has to stay in the response is the part that’s true only right now.
https://apievangelist.com/2026/10/22/we-did-not-skip-hypermedia-we-moved-it-out-of-the-response/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/we-did-not-skip-hypermedia-we-moved-it-out-of-the-response.png
#skiphypermedia #richardson #response #mcp #http #arazzo #overlays #api
#rss #feeds #linksharing #qwibbit

2026-10-22 20:56:29 GMT

A Banker Said Finance Does Not Have Enough MCP Servers And They Are Right About The Banks
I was at a conference in New York yesterday, and someone from the financial industry told me there just aren’t enough useful MCP servers in their sector. I didn’t want to answer from my gut, so when I got back to the hotel I asked the catalog.
The short answer is that they are right about their part of the industry. They are wrong about the sector as a whole. The difference between those two answers is what this post is about.
The headline number is misleading
Across the three finance verticals on APIs.io (Banking, Financial Services and Financial Technology) there are 2,975 companies. 845 of them have at least one MCP row in the catalog. That sounds like a sector that has gone all in on agents. It hasn’t.
Of those 845 companies:
515 have only a candidate. A candidate is a tool list we derived from the company’s own OpenAPI to show what a server could look like. The company did not ship it. Nobody can connect to it. It is a map, not a road.
84 ship a server that only searches their documentation. It is useful for a developer writing an integration, but an agent can’t look up an account balance, start a payment or pull a statement through it.
245 ship a server that reaches the API itself. Some of those are gated behind a sales conversation or an OAuth flow, which is fine, and probably correct for money.
So the honest number is 245 out of 2,975, or about 8% of the finance companies we track. Most of them aren’t banks.
Who actually shipped
The servers you can connect to come from fintech infrastructure and data vendors. Mercury, Moov, Lead Bank, Lili, Memo Bank, Atlar, Basiq, Airwallex and Afterpay are moving money and reading accounts. Alpaca does brokerage. Alpha Vantage, Aiera and Amberdata do market data and research. Anchorage does custody. Cumbuca connects Brazilian bank accounts to an assistant through Open Finance. Narmi, with Grasshopper Bank in August 2025, put out what is described as the first MCP server deployed by a U.S. bank.
These are companies that were already API-first. MCP was a short walk for them.
Who didn’t
Then I filtered for the institutions the person I talked to actually works with. There are 133 finance companies in the catalog that we tag Fortune 100, 500 or 1000. 120 of them have no MCP row at all. Citi, Barclays, Deutsche Bank, Truist, KeyCorp, Groupe BPCE and the UK open-banking group (Halifax, Bank of Scotland, Metro, Danske UK and the rest) exist in the catalog only as candidates we drew from their published OpenAPI. They have the APIs. They have not put an agent interface in front of them.
At most three of the 133 have something more. Intuit has a QuickBooks Online MCP server on GitHub. CarMax put its inventory in the ChatGPT app store, which is an agent surface but not really a finance one. Fifth Third’s record points at a sandbox API that I want to re-verify before I count it. The most interesting case isn’t on that list: Apollo Global Management runs an auth-gated MCP server on api.apollo.com that isn’t mentioned on any public Apollo page. We only found it by probing.
So the big institutions are building, but quietly, internally, and behind their own identity providers. That matches what I wrote about companies hiring for MCP: enterprises are ahead in job postings and behind in what they publish.
Why the gap is where it is
I don’t think the gap is a technology problem. The banks have OpenAPI. Many have FDX, open banking or ISO 20022 APIs that are already strictly regulated. What they don’t yet have is an answer to the questions an agent raises the moment it can act on an account:
Whose consent is the agent operating under, and how is that consent scoped and revoked?
How do you tell an agent acting for a customer apart from an agent acting for an aggregator?
What does the audit trail look like when a tool call moves money?
Which operations are read-only and safe to expose today, and which wait?
The fintechs that shipped answered those questions for their own customers, or limited themselves to read-only tools. The incumbents are waiting for answers that hold up in front of a regulator. That is a reasonable thing to wait for. But it means that the people inside those institutions, like the person I met yesterday, look out at the market and see nothing they can use.
What I would do with this
If you are at a bank and want to move, don’t start with a server. Start with the read-only operations you already publish (product reference data, branch and ATM locators, rates), and expose those first. Our candidate files are a starting point: they are generated from your own contracts, and each one is a list of the tools an agent would expect. That is the cheapest way I know to find out what your institution needs to decide before anything that touches an account goes live.
If you are a fintech that has already shipped, tell the banks you partner with. The best argument for MCP inside a bank is a sponsor-bank partner that already did it safely.
The data is all on APIs.io. Filter MCP by the banking or financial services tags, and look at the status on each server. Shipped, gated, docs-only and candidate are four very different answers to the same question.
https://apievangelist.com/2026/10/22/a-banker-said-finance-does-not-have-enough-mcp-servers-and-they-are-right-about-the-banks/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/a-banker-said-finance-does-not-have-enough-mcp-servers-and-they-are-right-about-the-banks.png
#mcp #mcpservers #bank #newyork #financial #onlinemcp
#rss #feeds #linksharing #qwibbit

2026-10-22 20:22:39 GMT

Payments And Banking: The Shape Of The Answer
Earlier this week I wrote about DeepInfer and the shape of the answer. Batch-invariant inference, deterministic sampling, and output constrained to a JSON schema or grammar now ship together in the open. Valid JSON is table stakes. The hard part is agreeing on the shape. Payments and banking is the industry where I expected that part to be easiest, because the shapes have been written down for a long time. So I went and looked.
The answer this industry needs
The business outcomes here are not abstract. A finance team gets a PDF invoice and needs a valid credit transfer instruction. A supplier sends a remittance email and someone has to match it to a line on a bank statement. A customer writes three angry paragraphs about a charge and an operations team has to turn that into a structured dispute.
Turn an invoice into a payment instruction. Turn a remittance note into a reconciliation entry. Turn a narrative into a case a bank system will accept. Every one of those ends in a message that a bank, a network, or a ledger will reject outright if one field is wrong. Nobody in this industry wants a creative answer. They want the same correct answer every time.
The shape is already written down
ISO 20022 is the shape for money movement. The message names are the vocabulary practitioners already use: pain.001 for a customer credit transfer initiation, pacs.008 for the interbank credit transfer, pacs.002 for payment status, and the camt family for cash management and statements. I could not load iso20022.org from here today (it returned a 403), so I am leaning on how these names show up in the providers’ own contracts, which I did read.
On the account data side, there are several regional shapes. FDX in the United States. The Berlin Group NextGenPSD2 framework in Europe. The UK Open Banking Standard. Australia’s Consumer Data Standards under the Consumer Data Right. Each one names the accounts, balances, transactions and payment consents a compliant API has to return.
The APIs.io standards page shows how many catalog providers carry each as a tag:
ISO 20022: 20 providers
FDX: 13 providers
Consumer Data Standards: 30 providers
Open Banking Standard: 40 providers
NACHA: 53 providers
Berlin Group NextGenPSD2 and the UK Open Banking Standard entries: no provider tagged yet
There is also a profile for each in the API Evangelist standards catalog, including ISO 20022 and FDX.
What the catalog holds
I used three cohorts from the Markets layer: payments, open banking, and US open banking (FDX). The payments cohort is 25 providers with a mean Kin Score of 69.1. Stripe leads at 81.1, then Uphold at 79.2 and Square at 78.1. The open banking cohort is 24 providers with a mean of 63.4, led by Plaid at 84.6, then IBANforge at 72.0 and Token.io at 71.6.
The US open banking cohort is the story. It is 25 providers with a mean of 38.4. Plaid is at the top again at 84.6, MX at 65.4 and Citi at 61.4. Then it falls off. Chase is at 33.4, Capital One 32.0, PNC 10.6, Fidelity 7.8, and The Clearing House 13.1. The aggregators that sit between banks and apps score well. Most of the banks whose data is being shared score thin or below in what they publish publicly. Agent readiness tells the same story, with Capital One, American Express and USAA at 3.1 and PNC and Fidelity at 0.
Across the 70 distinct providers in those three cohorts, I counted artifact folders in their repos: 53 have JSON Schema, 57 have vocabularies, 47 have AsyncAPI, 17 have examples, 15 have JSON Structure, and 8 have Arazzo workflows. A good share of those schemas and vocabularies are API Evangelist’s own derived work, not something the provider published, so read the counts as what the catalog holds, not what the industry ships.
The part that matters is the provider-published contracts that name ISO 20022 messages directly. Citi’s original OpenAPI files reference pain.001.001.03 and pacs.008.001.08. Barclays publishes a file payments contract built on pain.001.001.08. SoFi’s payment hub contract talks about pacs.008 or pacs.004 messages being published to the network and awaiting a pacs.002 status. Currencycloud and Truist (BB&T) reference pacs.008 in their own contracts too. That is the shape of the answer, already sitting inside the OpenAPI a model would be asked to call.
What determinism changes here
Payments are reconciled, audited and regulated. Every one of those properties assumes that the same input gives the same output.
If a model turns an invoice into a pain.001 today and a slightly different one on Friday because another request landed in the same batch, the reconciliation breaks and nobody can explain why. Batch-invariant inference removes that. Deterministic sampling means an auditor can rerun the same invoice through the same model and get the same instruction, which is the closest thing to a reproducible decision this industry will accept from a model. Constrained output means the model cannot invent a currency code, a purpose code, or a status that the scheme does not define, because the vocabulary is the grammar.
Volume matters too. Banks process these messages by the million. A structured answer that comes back valid 99 percent of the time is a queue of exceptions somebody has to work by hand. A structured answer that can only be produced in the schema’s shape moves the remaining errors from formatting into meaning, which is where a human reviewer should be spending time anyway.
Where it falls short
The standards exist. The publishing does not keep up. Berlin Group NextGenPSD2 and the UK Open Banking Standard have no provider tagged in the catalog yet, even though I can see Berlin Group references in several provider repos. That is a tagging gap on our side. The bigger gap is that the large US banks named in the FDX cohort mostly do not have a public FDX contract I can find. The shape is defined, but it sits behind partner agreements and aggregators rather than in a public OpenAPI.
ISO 20022 is published as XML schemas from the registration authority. Most providers who use it describe it in prose or embed XML examples in a JSON API. A few schemas in the catalog, from BB&T, Atlar and Banco Inter, mention pacs.008 in their fields or descriptions, but I could not find one that is a JSON Schema of the message itself that a constrained decoder could consume directly. That translation is still left to every team.
I left card network dispute and reason codes out of this post entirely. I could not source them from a public machine-readable place today, and I am not going to guess at them.
The close
Payments is the industry that should benefit first from constrained, deterministic inference, because it already did the hard work of agreeing on the shape decades ago. What is missing is the last step: the banks and networks publishing those shapes as machine-readable contracts where a model, and the people governing it, can find them. The aggregators have done it. The fintechs have mostly done it. I would like to see the banks do it too, because the answer is only as good as the shape you hand the model.
https://apievangelist.com/2026/10/22/payments-and-banking-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/payments-and-banking-the-shape-of-the-answer.png
#openbanking #shape #answer #consumerdata #datastandards #fdx #berlingroup #iso #json #turn
#rss #feeds #linksharing #qwibbit

2026-10-22 19:48:03 GMT

Who Owns The Agent: The Panel At Tyk LEAP ON TOUR In New York
After my keynote at Tyk’s LEAP ON TOUR in New York yesterday, Buddha put me on a panel with Kelly Rogers, who spent five years building AI infrastructure and running AI enablement for about 17,000 engineers at Capital One and now runs a governance consultancy for regulated industries, and Irene Aldridge, a quant and systems architect who teaches at Cornell, runs a data business and has just launched a startup around statistical monitoring of model outputs. The camera battery died at thirty-seven minutes, mid-sentence, so the video below ends the way my GoPro did. What was captured is the most useful conversation I have had about agent governance in a while, because none of it was about MCP.
What production means
Buddha opened by pointing at my traffic numbers and asking where agents actually are in production, as opposed to pilots. I pushed back on the word. Production is the gold star we all want, the well-honed assembly line we finally got dialed in for software, and agents are not on it. They are everywhere else. While we were talking, Claude was running on my laptop at the back of the room, orchestrating two more machines at home, publishing API profiles to APIs.io in batches overnight. I suppose that is production. It is production because I know what it is doing, because I put guardrails around it. The companies I work with are mostly finding success locally, in personal tasks, in the CI/CD pipeline, in the Google workspace, inside the construct their organization has given them. What counts as production is relative to the group, and a little more control and a little more automation is a healthy enough bar to learn from.
Kelly’s definition was sharper and I have been repeating it since. An agent is ready for production when someone who did not build it can tell you what it does, who authorized it, and how to shut it off. If someone else can tell you that, you are good.
Why banks lead
My industry table shows banking and payments ahead of the AI companies on agent readiness, and Buddha asked Kelly to explain it, given how risk-averse the sector is. Her answer was that banks are not braver than anyone else. The muscles already existed. Back in 2021 they were deploying models for fraud detection and credit worthiness under regulation, and the thing that mattered was never only that the model was accurate. It was that someone was named. If this does not work, this person is responsible. That ownership muscle is the springboard, and it is why nothing touches money or customers until it is in place. It does not diminish what happens in staging or on a laptop. It just sets the standard for the thing that moves money.
That is the same finding my catalog produces from the other direction. The banks that conform to PSD2 and the Open Banking standards are more than twice as likely to be agent-native as banking at large, because the standards forced the contracts, the consent flows and the error catalogs a decade before anyone said agent. Regulation built the muscle. The agents inherited it.
Who takes responsibility
Laura Heritage from Tyk asked the question the whole morning turned on. How do you get a person to say yes to owning an agent, when the pitch is “I configured it for you, trust me, and if it goes wrong it is your fault”? Kelly said people in a bank will happily own pieces of a workflow and almost nobody will own the whole process. Her example was the one everyone recognizes: change your address, then apply for a credit card, and three groups light up at once, the people who issue cards, the people who manage your account, and fraud, because that sequence is a strong signal of a stolen identity. An agent moving that workflow needs a person who owns the entire thing, and the people who stepped up were the ones who had committed to the organization launching an agent in the first place.
Someone in the room pressed harder. Deterministic software goes wrong and you go back to product and engineering. A probabilistic system goes wrong and the engineer says, not mine, I have no idea what it is going to do. Kelly’s answer was that this is exactly why the new roles are appearing, the AI product owner, the forward-deployed engineer, the agent steward, and that in practice ownership starts with whoever owns the KPI or the ROI that justified going agentic. Buddha added the part I want to keep: ownership has to mean transparency rather than blame, because there are more pieces in the chain than request and response ever had, and more places for it to break.
Fighting probabilistic models with statistics
Irene’s position is that an agent has a random number generator inside it, which is what gives you the out-of-the-box thinking and also the crazy ideas. You do not fight that with rules. You fight it with statistics. Track the distribution of a model’s outputs against its inputs, set the deviation you are willing to tolerate, flag the prompts that went out of range, and automate the kill switch so it fires at three in the morning without waiting for a human. Wrap agents with risk agents. Claude already runs an actor with four critics, she said, and the more critics, the more acceptable the output.
Her example of how chained agents bypass every individual safety check is the one I will remember. Ask one model for an innocuous image of people building a machine in a street. Pass it to a second model, with no context, and ask it to put the people in specific ethnic clothing. Pass that to a third and ask it to add an explosion. Each model checked its own request and passed it. Together they produced something none of them would have made. That is just an image. The same pattern works for fraud. Her conclusion is that you govern each off-the-shelf agent individually against its worst case, and you put a monitor over the chain.
Someone asked who governs the monitor. Irene called it an open research problem, and said that for now statistics suit statistical models, and that the reason contracts still live on blockchains is that nobody has made an agent produce deterministic output from one.
Contracts are the deterministic part
Buddha asked whether Arazzo and OpenAPI, workflows over contracts, give enough control. My answer was that it is never enough in a probabilistic world, but that the contracts are the part you can actually hold. OpenAPI for the surface, AsyncAPI for the events, JSON Schema to validate what goes in and what comes out, JSON-LD for the semantics, an Arazzo workflow that says make this call, then this one, then this one. I harvest all of those on APIs.io and you can bundle them differently for different industries, FHIR for healthcare, the open banking profiles for finance, and hand the bundle to an agent as its context. What DeepSeek open-sourced the week before, infrastructure that lets you put a JSON Schema on the inputs and outputs of any model, levels that field. The move is to make the model one small, precise, constrained piece of a process, a decision model with contracts on both sides and a named person or role controlling it, rather than a general intelligence you hope behaves.
Regulation, sovereignty, and three things
A question from the floor about US states passing their own AI laws got three different answers. Kelly: in finance and healthcare, keeping up with regulation was always the job, so build the framework once, get ahead of things like ISO 42001 even when nobody requires them yet, and above all make the governed path the easiest path. If following the framework is harder than going around it, people go around it, and that is where shadow MCP comes from. Governance that is hard to follow is how you get ungoverned agents.
Mine was about sovereignty. I had just come back from Stockholm, after London, Amsterdam and Munich, and every conversation in the EU member states is about running the models and the software in their own country. They are afraid of dependence on US frontier models and of what the US government might do with them. The Lovable team told me their biggest challenge is that they do not know what Trump will do with AI models, so they are centering on DeepSeek. Open-source models, open weights and open infrastructure, with contracts around them, are how you survive a landscape that volatile, and which country you operate in is going to matter more, not less.
Irene’s was the finance regulator’s view. The Fed’s model risk guidance says understand your models, which was written for a world where a validation team spent three months on each one. Now a model is obsolete in three months. So, three things: an inventory of every model you have, validation that inputs and outputs stay consistent, and kill switches for when they do not. Everything else is catching up.
Trust outside finance
The last question before the battery went was from someone working on ocean data who wanted to know how to build trust in raw data and model outputs in an industry that has no validation regime built in. Irene’s answer was to stop trying to understand the weights. A model has a billion of them, they can move by a thousand percent between periods, and they do not represent anything a human can audit. Approximate the function from inputs to outputs instead, track whether that mapping holds over time, and kill the model when it drifts. The questioner’s follow-up was the governance point: doing that is one thing, being open that you do it is another, because the people depending on your model need to know.
That is where I was when the camera died. My rating system tracks inputs and outputs for APIs the same way, not just for models: which SMS service you send through, which email provider, where the data came from, declared and measured. A trust framework is the measurement plus the declaration, and the piece I am building now is letting providers measure their own and feed it back to me. The recording cuts off as I was explaining what Claude was crunching on the laptop at the back of the room. It was doing several markets at once. That, apparently, is production.
The keynote and Buddha’s opening are also up, and the deck with every figure is at talks.apievangelist.com.
https://apievangelist.com/2026/10/22/who-owns-the-agent-the-panel-at-tyk-leap-on-tour-in-new-york/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/who-owns-the-agent-the-panel-at-tyk-leap-on-tour-in-new-york.png
#newyork #tour #leap #tyk #panel #agent #production #irenealdridge #buddha #kellyrogers
#rss #feeds #linksharing #qwibbit

2026-10-22 19:13:53 GMT

We Had The Agent Protocol In 2008 And We Left It On The Table
On November 20, 2008, Leonard Richardson stood up at QCon and gave a talk he styled after an episode of This American Life. Three acts and a conclusion. The third act was called “The Maturity Heuristic,” and two years later Martin Fowler wrote it up as the Richardson Maturity Model. Most of us have seen the pyramid. Fewer of us have gone back and read the talk itself. I did this week, and I can’t stop thinking about how much of what we are scrambling to build for AI agents was sitting right there on the slides.
What Leonard actually said
Leonard never called it a model. It was a heuristic for judging a web service by how many of the web’s core technologies it actually uses: URIs, HTTP, and hypermedia. Pick zero, one, two, or three.
At the bottom are the XML-RPC and SOAP services that look like “a C library,” with every function reached by a POST to a single URI. He compared them to the Flash restaurant websites of the day, “a little web-based peephole into some other universe.” One step up, you give each thing its own URI. He pointed out that Flickr, del.icio.us, and Amazon ECS weren’t RESTful, but they succeeded anyway because “they give each individual thing in their universe a URI.” People love URIs. Next you use HTTP methods to say what you want: “The URI means ‘That’ and the HTTP method means ‘Gimme.’” GET is safe and idempotent, which is what makes caching and conditional requests work.
Then hypermedia. Amazon S3 made you learn the rules for building keys from documentation, which he said creates “a coupling between the client and this particular web service.” Netflix put real links in its documents. “Connections between resources are a form of data, and they should be described in the documents with the rest of the data.” And the line I keep coming back to: “Links tell you where the resources are, and forms tell you what you can do to the resources.” A stock purchase and a wiki edit are both just POSTs at the HTTP level. “It’s the forms that give them semantics.”
Why we stopped climbing
I have spent sixteen years watching providers stop at the second step, and I don’t think it was ignorance. Leonard told us why in the talk itself. He said the hard part of hypermedia is the client deciding what to do next, that it “is still a difficult task, in fact it’s the most difficult part.” In 2008 the only client that could read a form it had never seen and decide what to do was a human sitting at a browser. Every API consumer was a developer writing code ahead of time against documentation. If a person is going to hard-code the workflow anyway, links in the response are a nice-to-have, and the cost of designing media types, link relations, and forms falls entirely on the provider with no visible return.
So the incentives ran the other way. Twitter, Facebook, and Stripe shipped good-enough JSON at the second step and won on developer experience. JSON never had a native link or a form, the way HTML did, so hypermedia meant picking one of HAL, Siren, JSON-LD, Collection+JSON, or JSON:API, and nobody agreed on one. Swagger, then OpenAPI, gave us a contract we could generate SDKs and documentation from, and code generation is the opposite of runtime discovery. It moves knowledge out of the response and into the client at build time. The mobile and single-page-app era wanted fewer round trips, which eventually got us GraphQL. And the people making the case for hypermedia often made it as a matter of purity, which never sells to a product manager with a deadline.
None of that was irrational. It was a market of human integrators, and for human integrators the second step was enough.
The client finally showed up
That’s what has changed. An LLM agent is the first client that can plausibly do the “most difficult part” Leonard described. It can read a response, notice a link with a relation it understands, read a form describing an action, and decide whether to take it. The thing hypermedia was always waiting for has arrived.
And look at what we built for it. MCP’s primary transport is JSON-RPC: one endpoint, method names in the body, a list of functions pulled from the server. That’s the bottom of Leonard’s heuristic, the C library behind a single URI. To be fair, listing tools at runtime is a small step toward discovery, more than SOAP ever gave us. But the results rarely link anywhere, and the protocol doesn’t tell you which calls are safe. So we are now bolting readOnlyHint and idempotentHint annotations onto tools to describe what GET already said at the protocol level. We are relearning steps one and two, one annotation at a time.
Leonard also warned us about the button. In his conclusion he talked about George Jetson, whose whole job is pushing a button while robots do the work. Tools that promise to turn your server code into a client with one push “pretend the network boundary isn’t there,” and “the button is not smarter than you are.” Every unnecessary bit of complexity on the provider side gets passed on to every client. Generating three hundred MCP tools from an OpenAPI spec is the 2008 button with a new consumer, and that consumer pays for every bit of extra complexity in tokens and wrong guesses.
What this means for providers
I don’t think the answer is a hypermedia revival with a new acronym. Leonard’s three closing principles are still the right guidance: split complexity into small pieces, treat similar things the same way, and describe the differences in a standard way so people can learn them quickly. For agents, that means:
A URI for everything. It’s still the cheapest step and still the one that matters most. Agents cite, fetch, and hand off by URL.
Don’t throw away HTTP’s semantics when you wrap an API for agents. Safe versus unsafe is the single most important thing an agent needs to know before it acts.
Put the next step in the response. Pagination links, related resources, and the actions currently available, described with link relations and schemas the agent can recognize, instead of rules that only live in the documentation.
Describe differences in shared standards. OpenAPI, Arazzo, JSON Schema, and registered link relations, not prose that is unique to every vendor.
We had the protocol for automated clients in 2008. We just didn’t have the client. Now we have the client, and most of the APIs it talks to are still at the second step, or at the bottom with a new name. The question I’m asking providers now isn’t “are you RESTful?” It’s how much of what an agent needs to know is in your responses, and how much is only in your docs.
https://apievangelist.com/2026/10/22/we-had-the-agent-protocol-in-2008-and-we-left-it-on-the-table/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/we-had-the-agent-protocol-in-2008-and-we-left-it-on-the-table.png
#http #leonard #uri #americanlife #richardsonmaturity #martinfowler #links
#rss #feeds #linksharing #qwibbit

2026-10-22 18:39:40 GMT

Trust You Can Carry Has To Be Written Down
Mike Goerlich at Curity published the third piece in his Security Sovereignty series today, Who Controls Trust? How Do You Regain It?, and I want to respond to it, partly because he was kind enough to quote me in it and partly because I think it lands on the most important point in the whole conversation about agents.
His argument is that portability is usually understood as moving workloads: containers, replicated databases, infrastructure as code. That’s useful, but it is only one layer. You can move an application perfectly and still leave behind the identities it trusts, the authority it grants, the business rules it enforces, and the trust relationships it depends on. At that point a migration problem has become a business continuity problem.
The line of mine he quoted came from our conversation about his first article: you cannot be sovereign over trust that was never made explicit. He builds on it better than I said it. “An authority boundary that exists only implicitly gives you nothing to carry with you.” And: “Before trust can become portable, it must first be visible.”
Where authority actually lives
The example Mike uses is perfect. A business may know exactly where an application runs and still be unable to say where the rule lives that lets a customer cancel their own reservation but not someone else’s. Some of it is in application code. Some is implied by a scope. Some lives in a gateway, some in the identity provider, some in the user interface, and a lot of it lives in the heads of the people who built the system.
I see the outside view of that every week. When we profile an API provider for APIs.io, authorization is one of the places where the published surface tells you least. The Agent Readiness re-measure I took into Stockholm this month, across roughly 28,900 providers, found that about a third publish machine-readable auth of any kind, a quarter of the catalog hands out a static bearer secret that names nobody, and eighteen providers issue a credential bound to the agent using it. Scopes, where they exist at all, are often a handful of coarse permissions that say more about the implementation than about the business rule.
That’s the visible part of the problem Mike is describing. If a provider hasn’t written its authority model down in a form anyone outside can read, it almost certainly hasn’t written it down in a form it could carry to another environment either.
Writing the authority down
Mike says the harder and more valuable work is “making the organization’s intent explicit: what authority should be granted, how narrowly it should be bounded, which resources it applies to, and how APIs should respond when that authority changes.” I agree, and I would add that most of the containers for that intent already exist as artifacts. They just aren’t being treated as the place the authority model lives.
OAuth scopes published as data, with a description that says which business action each one permits, not just which endpoint.
Security schemes in the OpenAPI contract, attached operation by operation, so the boundary is in the contract and not only in a gateway’s configuration.
Protected resource metadata (RFC 9728) and authorization server metadata, so a client, or an agent, can discover how to get the right authority without a human reading a docs page.
Agentic access declarations, per operation: what it costs, whether it can be undone, and where a human has to approve it. This is the closest thing I’ve found to Mike’s “rules for how authority changes when conditions deteriorate”, written down before anyone needs them.
Know Your Agent attestations, so the question of who is acting is answered by facts a provider can check, while the decision to trust stays with the provider.
None of these are proprietary to a platform. They are plain documents that sit beside the API. If they exist, they move with you. If they don’t, the authority lives only in the platform you’re trying to leave.
Agents make it urgent
Mike closes on the point I care most about: with agentic AI, what has to survive a move isn’t just identity, it is “the meaning of the agent’s authority: what it is allowed to do, which resources that authority applies to, and where its boundaries lie.” And he’s right that a generic admin role is a terrible substitute, because “all that really means is that excessive authority can travel with you.”
Yesterday I wrote about Mike Amundsen’s axioms for autonomy, which say an autonomous program needs its environment made explicit as facts, relations and capabilities, including knowing when progress is no longer possible. Two Mikes, two very different starting points, the same conclusion. An agent can only respect a boundary it can read. An organization can only keep a boundary it has written down. Both require the authority model to stop being implicit.
That is also why I keep saying this is API governance work, not AI work. The scopes, the security schemes, the reversibility and approval rules, the metadata documents: these were always supposed to exist. The difference now is that a non-human consumer will act on whatever is there, and a change of provider will reveal whatever isn’t.
Making it measurable
The last thing I’d add to Mike’s series is that this is measurable from the outside, at least in part. You can see whether a provider publishes scopes, whether its contract declares security per operation, whether it serves protected resource metadata, whether its credentials are bound or bearer, whether it says which operations need a human. Those are all checks in the Kin Score and its agent readiness layer today. They don’t tell you whether the authority model is right. They tell you whether it exists anywhere other than inside one platform and a few people’s heads.
Mike’s line that “an organization cannot move control if it does not know precisely what needs to move” is the one I’ll be quoting back. Thanks to him and the Curity team for taking the conversation somewhere more useful than “should we leave the cloud.” The answer to that question is usually no. The answer to “have we written our trust down?” is usually not yet.
https://apievangelist.com/2026/10/22/trust-you-can-carry-has-to-be-written-down/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/trust-you-can-carry-has-to-be-written-down.png
#trust #securitysovereignty #mike #controlstrust #mikegoerlich
#rss #feeds #linksharing #qwibbit

2026-10-22 18:05:19 GMT

Discovery Is The First Governance Control: My Keynote At Tyk LEAP ON TOUR In New York
Yesterday morning I opened Tyk’s LEAP ON TOUR: The Future of MCP Governance in New York, a room of about thirty people who decide how their companies will govern agents, most of them from finance. Buddha gave me twenty minutes to set the stage before a panel with Kelly Rogers and Irene Aldridge. I did it in eighteen. The video is below, the deck is online, and this post is what I said, with the numbers I rounded on stage put back the way the catalog has them.
Tyk’s line for the day was that every call is an ungoverned path unless something inspects it. That is right. I added one thing to it: nothing can inspect a path it has not found. Discovery comes first. Everything that follows is the evidence for that sentence, read from the APIs.io catalog as it stood on October 17, which is 31,229 API providers and 154,842 APIs profiled and scored on two instruments that never touch each other, the Kin Score for governance and Agent Readiness for whether an autonomous agent can drive the API without a human filling in the gaps.
MCP server is three different numbers
When a vendor, an analyst or your own platform team says “we have N MCP servers,” ask which N. In the catalog there are 6,968 MCP entries, which is anything a provider says about MCP in a machine-readable way. Of those, 4,041 are real servers, a manifest with a server behind it. Of those, 3,321 are hosted endpoints an agent can actually open. The rest is theater: 2,774 are declared with nothing reachable behind them, and 691 are a documentation page about a server rather than a server.
I have published the wrong one of those three numbers myself, in print, and corrected it the next week. The reason this matters for the room is that every enterprise estate has the same three numbers. The gap between declared and reachable is what the Chicago stop of this tour named shadow MCP. The gap between reachable and registered is what the whole day was about.
Reachable is not governed
My agents probed 2,548 of those remote endpoints with an anonymous initialize. 836 of them, a third, let the anonymous client in. 1,463 refused with an auth challenge. 143 were dead hosts and 17 were not MCP at all. When I probed a random eighty by hand, two were uninstantiated templates: https://<JFROG_PLATFORM_URL>/mcp and /mcp/{ACCOUNT_ID}, copied out of the documentation with the placeholder still in the URL. An agent does not know what your server name is. It is not an existing customer.
The authorization gap
The MCP specification’s authorization model depends on a server advertising RFC 9728 protected-resource metadata so an agent can find the authorization server at runtime, register itself under RFC 7591, and get a token scoped to the human it acts for. Across 31,004 scored providers, 2,075 publish that metadata, which is 6.7%, and only 140 of them serve it at the /mcp path itself. 1,617 offer dynamic client registration, 5.2%. 2,530 serve delegated user identity, 8.2%. Meanwhile 7,710 providers hand out a bearer token or an API key and nothing else. Fewer than one in ten providers publish what an agent needs to authenticate as the person it works for, and the rest give the agent a credential that belongs to the integration. An audit log that cannot name the delegated subject cannot answer the question your CISO will ask. That is where a gateway doing token exchange earns its keep, because almost nobody has it in the API.
Curated or generated
Of the 4,408 servers where my agents captured a tool list, the median server has 12 tools. 182 have more than a hundred, and the largest has 1,029. Among servers with five or more tools, 42% are one-tool-per-operation generators, the names all get_this and create_that. Generating an MCP server from your OpenAPI is fine as a start. It is the new generating an SDK. But if nothing was done beyond the generation, the resources, the prompts, the security and the metadata an agent needs are not there, and the model is choosing between three hundred tools with its context window. I rate servers as generated, handcrafted or evolved, and the ones that work are small and shaped around a use case.
Discovery is federated
If you run an API program, your portal has been the front door. Agents do not start there. They start at your domain’s /.well-known location, and there are now about fifty documents that can live there. Across 10,809 providers probed at their own domains, 2,248 serve OAuth authorization-server metadata, 1,578 serve protected-resource metadata, 702 serve an RFC 9727 API catalog, 629 serve an A2A agent card, 573 serve an llms.txt, and 186 serve an MCP server card. The official MCP registry listed 1,900 servers on October 7 and 46,293 twelve days later, which is bulk publishing rather than adoption, with a single Cloudflare Workers host accounting for 2,365 of the entries. Of the 3,194 hosts behind the catalog’s hosted endpoints, one in six appears in the registry at all. There is no single place to look, and there will not be. Inside your company it is the same shape, and if your governance program does not start with a discovery surface, the servers it cannot see are the ones that matter.
Readiness does not rise above the foundation
This is the finding I have carried through Toronto, London and Stockholm this autumn, and it keeps holding. Across 31,005 providers the governance composite and the agent-readiness rating correlate at r = 0.870, and 94.9% of providers score readiness at or below their governance. Of the 434 providers in the exemplar governance band, 21.9% reach agent-native. Of the 13,883 in the bottom band, zero do, and some of them have shipped MCP servers. The dimensions that move readiness are not AI features: idempotency keys on writes, which 3.9% of providers declare; stable error semantics, 20.3%; documented reversibility, 7.3%; a dry-run on destructive operations, 0.6%. They are API disciplines that were always supposed to be there, now load-bearing because there is no developer in the loop to work around their absence. Getting the server up is the easy part.
The one asterisk is the 1.4% whose readiness exceeds their foundation. When I went looking, most of them were facades, companies with a polished MCP server and no business underneath, built to be sold on the secondary market.
Standards are how an industry meets this moment
The room was finance, so I showed them their own sector. Providers that actually conform to PSD2 and the Open Banking family, 178 of them graded at the contract, are 9.6% agent-native against 4.3% for banking at large, with a median readiness of 27.4 against 3.2. The 102 that conform to FHIR are 3.9% agent-native against 0.4% for healthcare at large, where the median readiness is zero. Agents understand standards. They hallucinate less across ten APIs that share FHIR than across ten APIs that each invented their own shape. The caution is that claimed is not conformant: 1,093 providers declare FHIR and 102 conform. A standard stabilizes an industry only when it is shipped at the contract, and MCP, A2A and RFC 9728 are the next entries on that list.
Monday
I closed with the list I would hand any of the companies in that room.
Inventory the three numbers for your own estate: declared, exists, reachable. The delta is your shadow MCP.
Publish discovery on your own domain: the API catalog, protected-resource metadata, a server card. Cheap, rare, and what every registry and scanner reads first.
Own the server’s design. Few tools, shaped around use cases, annotated for read versus write. A platform-generated server is a start, not an end.
Put identity in the path, so the agent carries the user’s identity rather than the integration’s key, and log the delegated subject.
Fix the APIs underneath where readiness is bounded: idempotency, error schemas, rate-limit headers, reversibility.
Measure it, on the same instrument, every quarter. Nothing moves the number except what you publish, which is exactly what makes it worth moving.
Nothing on that list is specific to MCP, and that was the point of standing in front of an API management company’s customers to say it. The gateway is where the inventory, the identity and the enforcement happen in one place.
The panel that followed, with Kelly, Irene and Buddha, went straight into who owns an agent in a bank and how you govern the agent that governs the agents. I wrote that up in Who Owns The Agent. In the meantime, the deck carries every figure with its snapshot date, and you can look your own company up on APIs.io before you decide whether any of this applies to you.
https://apievangelist.com/2026/10/22/discovery-is-the-first-governance-control-my-keynote-at-tyk-leap-on-tour-in-new-york/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/discovery-is-the-first-governance-control-my-keynote-at-tyk-leap-on-tour-in-new-york.png
#newyork #mcp #tour #tyk #leap #mcpgovernance #first #agent #discovery #irenealdridge
#rss #feeds #linksharing #qwibbit

2026-10-21 16:37:06 GMT

Three Hundred Eighty Companies Say Claude And One Hundred Forty-Two Say Anthropic
Job postings do not name AI companies. They name AI products.
That is the clearest thing in the Q3 2026 Insights pull when you line up the vendors against what they sell. The pull read 343,299 job postings from 984 companies — 775 in the Fortune 1000 and 209 API providers from the APIs.io catalog. As always, every number below is a count of companies whose postings name the term at least once, not a count of mentions.
The product beats the company
companies
share of the 984
Claude
380
38.6%
ChatGPT
287
29.2%
OpenAI
245
24.9%
Gemini
182
18.5%
Anthropic
142
14.4%
Hugging Face
107
10.9%
Llama
60
6.1%
Mistral
25
2.5%
Claude is named by 380 companies. Anthropic, the company that makes it, is named by 142. Two hundred fifty-nine companies say Claude and never say Anthropic; only twenty-one go the other way.
OpenAI is closer to its product, but the pattern holds. ChatGPT is in 287 companies, OpenAI in 245, and 126 companies name ChatGPT without ever naming OpenAI.
Nobody writes “experience with Anthropic” into a posting when what they want is someone who uses Claude Code every day. A posting asks for the thing you touch, and the thing you touch is a product: “comfortable experimenting with ai tools e g chatgpt claude copilot to accelerate research drafting and design”. The vendor shows up when the work is about choosing between models or integrating with them: “familiarity with the modern ai tooling ecosystem including llm apis anthropic openai agent frameworks”.
Wide versus deep
Company counts and posting counts tell different stories here.
companies
postings
share of all postings
Claude
380
2,560
0.75%
ChatGPT
287
5,092
1.48%
Claude is named by more companies. ChatGPT is named in twice as many postings. Claude is spread across more employers, and ChatGPT goes deeper inside the ones that use it, the kind of name that ends up in a standard list of office tools and gets copied into posting after posting.
There is one more name that would sit near the top of this list, and it is not here on purpose. GitHub Copilot and Microsoft Copilot share the bare word “Copilot”, so any count of one is quietly a count of both. Until those can be separated we report them together or not at all.
The API providers name Claude at 1.75 times the enterprise rate
Fortune 1000
API providers
Claude
33.3%
58.4%
ChatGPT
28.9%
30.1%
OpenAI
25.0%
24.4%
Gemini
17.8%
21.1%
Anthropic
14.1%
15.8%
Most of these rows are within a few points between the two groups. Claude is not. Fifty-eight percent of the API providers name it against thirty-three percent of the Fortune 1000, a ratio of 1.75. No other name in that table comes close to that gap, and it fits what the postings ask for: Claude often shows up as a coding tool, and API companies are mostly engineering organizations.
Same caveat as every week: the provider side is 209 companies against 775, so that is a direction, not a measurement.
By industry
Here is the share of companies, by industry, whose postings name at least one of OpenAI, ChatGPT, Anthropic, Gemini, Mistral, Hugging Face, or the OpenAI APIs. Industries with at least fifteen qualified companies.
industry
with an AI vendor
companies
share
Financial Technology
12
16
75.0%
Media
12
17
70.6%
Technology
26
41
63.4%
Enterprise Software
21
37
56.8%
Financial Services
47
89
52.8%
API provider
102
209
48.8%
Professional Services
7
16
43.8%
Healthcare
30
70
42.9%
Insurance
13
31
41.9%
Retail
12
29
41.4%
E-commerce Platform
8
20
40.0%
Automotive
11
28
39.3%
Construction
6
21
28.6%
Consumer Goods
14
53
26.4%
Energy
10
38
26.3%
Utilities
4
18
22.2%
Industrial
15
77
19.5%
Logistics
3
16
18.8%
Fintech and media at the top, industrial and logistics at the bottom. Some of those industries are small, so a single company moves them several points. Financial services, with 89 companies, is the one I would put the most weight on, and it is above half.
Notice which name is missing from that list: Claude. The industry table counts a fixed set of vendor and model names, and Claude is not in it. Add Claude back in and the number of companies naming at least one AI vendor or model goes from 415 to 497. For the API providers it goes from 48.8% to 68.9%; for the Fortune 1000, from 40.4% to 45.5%. Eighty-two companies name Claude and none of the others. If you count AI vendors and leave out the product names, you are undercounting the people who are actually hiring.
What I think it means
For anyone selling to these companies, this is a vocabulary lesson. The brand that lives in a job posting is the one people put their hands on every day, and right now for a lot of engineering teams that is a coding assistant, not a model API. If you are an API provider trying to understand how your customers will reach you through AI, the question is less “which model provider do they use” and more “which tool are their developers sitting in”, because that is where your MCP server, your docs, and your OpenAPI are going to be read.
It is also a warning for anyone, including us, who builds a market map from vendor names. Count companies and you miss the products. Count products and you collide with words that mean something else. Claude needed a sampled verdict before we would quote it, for exactly that reason.
How to read these numbers
This is hiring intent, not production use. Naming Claude in a posting says a company wants people who know it, not that it is under contract with Anthropic.
Q3 2026 is the first point in the series. Nothing here is rising or falling yet. The Q4 read comes out November 20, and that is the first comparison we can make.
Only verified terms are quoted. Every name above was matched on word boundaries and sampled against the postings before it could appear. The Copilot names and a couple of model-library terms did not clear that bar this quarter and are left out.
The full Insights data, including the AI vendors and models across every qualified company, is available through the APIs.io API and MCP server.
Three hundred eighty for Claude, one hundred forty-two for Anthropic. I would like to know whether that gap narrows or widens when we read Q4 on November 20.
https://apievangelist.com/2026/10/21/three-hundred-eighty-companies-say-claude-and-one-hundred-forty-two-say-anthropic/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/three-hundred-eighty-companies-say-claude-and-one-hundred-forty-two-say-anthropic.png
#api #chatgpt #openai #copilot #fortune #company #gemini #huggingface
#rss #feeds #linksharing #qwibbit

2026-10-21 16:12:06 GMT

Where The Market Layer Of The Kin Score Stands
Nine days ago I wrote that the Kin Score was getting a third dimension, the market. I want to show where that work stands, warts and all. We are building this in the open, and I would rather you see the rules, the numbers, and the open questions than just a polished score.
What the Market layer measures
The first two dimensions of the Kin Score look at a provider: what it publishes, and how ready that is for agents. The Market layer looks outward. It reads where each provider sits in its market, using evidence the market publishes itself.
The chain we are building is deterministic: operation → tag → business capability → workflow → integration → market. Every integration, registration, listing, or certification between two parties becomes an edge, and every edge cites where it came from.
Where the evidence comes from
Registers. Regulated markets already publish their own map. We read FedRAMP, the SEC’s investment adviser filings, ICANN’s accredited registrars, the Monetary Authority of Singapore, Bank Indonesia, Open Finance Brasil, the FAA, the FDA and ONC, the PCI Security Standards Council, Metrc, and Mozilla’s CCADB. We also read standards bodies like the CNCF, OPC Foundation, ODVA, BACnet, GS1, and Peppol.
Marketplaces. Open markets publish who builds on them. We read Salesforce, HubSpot, Shopify, Slack, Zoom, Microsoft Teams, Zendesk, Zapier, n8n, Airbyte, Fivetran, and others, and classify each listing as a platform app, a distribution channel, or an iPaaS bridge.
What providers say about themselves. Integration pages, A2A agent cards, and official SDKs published on package registries.
The finding that keeps holding up: open markets integrate through workflows, regulated markets integrate through standards.
How it is scored
Each provider gets a position: gravity, core, coverage, covered, standard, regulated, builds-on, distribution, long-tail, mixed, or undeclared. Within a position, depth comes from per-edge signals, never from counting edges. A listing earns participation. A certification earns depth, up to a ceiling set per register by the widest vendor actually in the data. FedRAMP caps at three impact levels, PCI at six programs, BACnet at eighteen device profiles. Lapsed certifications count for nothing.
The rules we hold ourselves to:
Breadth is not credit. A long list of logos earns nothing on its own.
Declaration is the provider’s responsibility. If a provider publishes nothing a machine can read, it reads “undeclared.”
Attribution. When something can’t be measured, we record whose gap it is, and our own gaps never count against a provider.
Domain, not name. We link on domains with a name check. When a register only gives names, we may resolve them through Wikidata or by an exact match against a single catalog repo, and every one of those edges says so.
Market fit. A company that shows up in a register outside its own business, like a retailer registered to sell money orders, is held rather than credited.
Self-filed registers need more. Anyone can file in some registers, and some people file under famous names. Those need the country to agree, and in the worst cases, a human review.
Report-only until proven. Shape compatibility, MCP registry listings, and agent registry listings don’t count until we have four weekly snapshots. A provider’s own A2A agent card becomes a declaration on November 2.
Conflict of interest. Our own sites are excluded, and so are agent cards we host on behalf of other companies.
How far it reaches
As of today there are 92 markets. Of the industries in our taxonomy, 74 are covered by a market, 5 partially, and 2 not at all. 33 technical areas are covered, and 180 tag groups. There are 3,788 providers holding 4,262 market memberships, and 376 of them belong to two or more markets. OpenAI shows up in six. Stripe, HubSpot, Cloudflare, Algolia, and Telnyx each show up in five.
The markets come in a few kinds:
Bedrock markets, like payments, healthcare, banking, and most industries, read by depth and structure.
Frontier markets, like decision models, model routing, and AI agents, read by movement over time.
Shape markets, like S3 storage, Postgres, Kafka, OCI registries, and Kubernetes, read by who speaks a common contract.
Catalog-wide markets, like official SDKs, which cut across everything.
What it has found so far
The pipes are in the registers, the brands aren’t. GS1 lists the data pools, not Procter & Gamble. Agriculture’s data businesses, nutrition APIs, sports data, and commercial weather APIs appear in no register at all.
Conformance and APIs live in different worlds. Industrial vendors certify against protocols. The API-first companies in the same markets certify nothing.
Registers can be gamed. FinCEN’s self-filed list is full of virtual-office registrations under famous names.
Officiality matters to agents. We found 5,008 official SDK packages across 1,808 providers, against roughly 8,900 community wrappers and forks.
The agent frontier is young but disciplined. 389 live A2A agent cards, three quarters of them conformant, and the early adopters are new companies rather than established API providers.
What is not settled
I want to be clear about what isn’t done.
It is still standalone. The Market layer doesn’t touch the composite Kin Score or Agent Readiness. It won’t until it has been stable across several weekly releases. How and when it feeds in is the biggest open decision.
The weights are a prototype. They are calibrated against my own read of each market. A position like “standard” still mixes a listing with a certification, and only depth separates them.
Frontier movement needs time. We have only a couple of weekly snapshots so far, and movement metrics mean little until there are more.
Some markets won’t let us read them. About 80 sources sit behind logins, bot walls, or client-side apps, including the Gulf financial registers. We won’t get around a login or a challenge to read them.
Our own catalog is a ceiling. Registers name hundreds of providers we don’t profile yet. Every harvest makes the markets more accurate.
The pages are behind the data. What we know is well ahead of how we show it.
What’s next
Markets go live on APIs.io with the next weekly build, and a market API will follow for Understanding-tier subscribers. After that comes calibration, more markets, a guide for providers on how to declare their integrations in a form machines can read, and a weekly read on how each market is moving.
If you are an API provider, the fastest way to show up well hasn’t changed: publish your integrations, partnerships, and certifications somewhere a machine can read them. If you think we have your market wrong, tell us. Corrections are free, and they make the layer better for everyone.
https://apievangelist.com/2026/10/21/where-the-market-layer-of-the-kin-score-stands/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/where-the-market-layer-of-the-kin-score-stands.png
#kinscore #marketlayer #open #standards #integration #pci #every #pcisecurity
#rss #feeds #linksharing #qwibbit

2026-10-21 15:47:06 GMT

What A Program Needs In Order To Decide
Mike Amundsen published a short one yesterday, Designing for Autonomy, while he finishes his new book, AI-Driven API Design. It’s two axioms he settled on while building GRAIL, his work on software that pursues goals without a human deciding what happens next. They are compact, and I have read them a dozen times since:
Designing Autonomous Systems — Designing autonomous systems means making enough of an environment explicit for programs to situate themselves within it, use a goal to determine what is relevant, decide what to do next, recognize success, and determine when progress is no longer possible.
Programming for Autonomy — Programming for autonomy means turning assumptions about an environment into explicit facts, relations, and capabilities so that programs can pursue goals within it without human intervention.
Then he says what changed for him: he moved from asking “what does the program need to do next?” to asking “what does the program need in order to decide what it will do next?”
That second question is the one I have been trying to answer with APIs.io without having the words for it. Most of what gets called context engineering right now is prompt text: instructions hand-written for one agent, in one application, describing an environment the agent has no other way to see. Mike’s axioms describe the alternative. Make the environment explicit, once, as facts, relations and capabilities, and let any program read it.
Five things a program has to be able to do
I read his first axiom as a checklist. An autonomous program has to be able to situate itself, find what is relevant to its goal, decide what to do next, recognize success, and recognize when it is stuck. Each of those maps to artifacts we already harvest, profile and score.
Situate itself in the environment. Before a program can do anything, it needs to know where it is: who this provider is, what it offers, how it relates to the rest of its market. That is the provider profile and the APIs.json index behind it, the well-known API catalog, and the industries and markets a provider sits in. A program that lands on a provider cold can learn its whole surface from one machine-readable index instead of a homepage.
Use a goal to determine what is relevant. A goal is usually stated in business terms, not API terms. Nobody asks to call POST /v2/invoices. They ask to get paid. That is what the business capabilities and use cases are for, mapping operations up to the outcomes a business cares about, and what the conversational phrasing in our Overlays is for, the questions people actually ask and the instructions they actually give, attached to the operations that answer them.
Decide what to do next. This is the part everyone focuses on, and it is the part with the most artifacts. The OpenAPI contract says what can be called and with what. The Arazzo workflows say what order things happen in and what passes between steps. Agent skills say how to operate a product, and the good ones say what the agent cannot do. MCP servers package the calls as tools.
Recognize success. A program can’t recognize success if it doesn’t know what success looks like. The schemas say what a valid result is shaped like, the examples show what real ones look like, and the vocabularies say which values are allowed. A 200 OK is not success. A response that matches the shape the goal required is.
Determine when progress is no longer possible. This is the clause I think most agent work skips, and it is the one that keeps an autonomous program from looping, retrying a payment, or burning a budget. Rate limits and plans say where the ceiling is. Error semantics say what a failure means and whether to try again. And agentic access says, per operation, what it costs, whether it can be undone, and where a human has to approve it. That is the explicit statement of where autonomy stops.
Facts, relations and capabilities
His second axiom names the three kinds of thing an environment has to be made of, and they line up with how the catalog is built.
Facts are the contracts and data shapes: OpenAPI, AsyncAPI, JSON Schema, JSON-LD, vocabularies, the standards a provider conforms to. They turn “I assume this endpoint takes a customer ID” into a fact a program can check.
Relations are how things connect: the integration graph between providers, the capability edges from operations to business outcomes, the corporate estates that say which providers belong to the same company, and the workflows that chain one API to another. Relations are what let a program reason across providers instead of inside one.
Capabilities are what can actually be done: the business capability model, the MCP tools, the skills, and the operations themselves, each with its access rules attached. And when the program is acting for someone, Know Your Agent is the part of the environment that says who the program is and whether a provider trusts it.
Explicit is the whole job
What I like about Mike’s framing is that it puts the work in the right place. Autonomy isn’t something you add to a model. It is something you make possible by writing the environment down. Every assumption a human used to carry in their head, which endpoint to call first, what a good result looks like, when to stop and ask, has to become an explicit fact, relation or capability, or the program will either guess or stall.
That is also why I think context engineering belongs to API providers and not only to the people building agents. The provider is the one who knows the facts. A provider who publishes a contract, a workflow, a schema, a rate limit and an access policy has done the context engineering for every agent that will ever call them. A provider who doesn’t has left every agent builder to reverse-engineer it, differently, one prompt at a time.
The question Mike ended on is the one I would put to every API team right now. Not what should an agent do with your API, but what does an agent need from you in order to decide.
https://apievangelist.com/2026/10/21/what-a-program-needs-in-order-to-decide/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/what-a-program-needs-in-order-to-decide.png
#program #designingautonomous #order #autonomy #needs #apidesign #systems #situate #use #mikeamundsen
#rss #feeds #linksharing #qwibbit

2026-10-21 15:22:16 GMT

Four Companies Serve Skills Over MCP The Way The Spec Says
On September 13 the Model Context Protocol made skills official. SEP-2640, the Skills Extension, went Final, and the working group behind it published a docs site with the stable specification. Five weeks later I wanted to know who is actually using it, so yesterday I asked every MCP server in our catalog.
Four companies serve skills over MCP the way the spec says to. Five, if you count us, and I am not counting us.
What the spec actually is
An Agent Skill is a folder with a SKILL.md file at its root: a name, a description, and the instructions an agent follows to do a specific kind of work, plus whatever scripts and reference files it needs. Until now, skills mostly lived in a repository or on a local disk, which is fine when an agent has a file system and less fine when it is running in a browser or on a phone.
The Skills Extension puts them on the MCP server. A server says it supports the extension by declaring io.modelcontextprotocol/skills in the capabilities it returns from initialize. Each skill gets a skill:// URI, its SKILL.md is the entry point, and its supporting files are resources under the same path. A client can list the skills with skills/list, and the skill files also show up in an ordinary resources/list. A couple of details from the maintainers’ review are worth knowing: a skill’s identity is the server plus its URI, not its name, and clients are not supposed to download every skill and file up front, which protects the server.
The extension is not part of the core protocol. It is an opt-in, versioned on its own, with a conformance suite in the official MCP conformance repository and SDK work underway in TypeScript, Python and C#.
How I counted
Our catalog records the MCP servers that providers publish. I took every endpoint we have on file, 9,170 URLs across 3,765 providers, and sent each one an anonymous initialize that offered the skills extension. 1,450 endpoints from 1,003 providers answered. The rest want a login, are gone, or are not something you can talk to anonymously. Wherever a server declared the extension, I followed up with skills/list and resources/list to make sure there were real skills behind the declaration.
So this is a count of public, anonymous MCP servers. A company could support the extension behind authentication and I would not see it.
The four who implement it
Hugging Face — huggingface.co/mcp. The deepest implementation I found. The skills are working material for its own platform: hf-cli, hf-mem, and a set of SageMaker deployment skills covering AWS context discovery, Python environment setup, IAM preflight, serving-image selection, a deployment planner and production defaults. They ship with more than a SKILL.md: the environment setup skill carries a requirements.txt and two Python scripts as resources. The server negotiated protocol revision 2025-11-25, and it is strict about it. My first follow-up call sent a newer protocol header and Hugging Face rejected it with a clear error naming the mismatch, which is what a server should do.
Glean — developers.glean.com/mcp. Glean’s developer documentation server serves two skills: docs-research, for working through its developer docs, and connect-glean-remote-mcp, for wiring an agent to Glean’s remote MCP server, with a troubleshooting reference shipped alongside it. That is the job I would most like to see skills doing everywhere: teaching the agent how to adopt the product, from the product.
Renoolab — mcp.renoolab.fr/mcp. A French platform for the building trades, and the most thoroughly packaged of the four. Two skills, one for creating and tuning an artisan’s profile and one for growing a contractor’s client base and visibility, written in French, with 50 resources between them: references, a document of the platform’s actions, and an agents/openai.yaml in each skill folder. Renoolab also declares the MCP Apps extension, so it is one of the few servers combining extensions, and it serves the same thing from a Cloudflare Workers mirror.
BestPrice — mcp.bestprice.gr/mcp. The Greek price-comparison service serves one skill, bestprice-shopping, which teaches an agent how to make read-only shopping decisions with its search, offers and price-history tools. One skill, done cleanly, listed in both skills/list and resources/list, and documented in the repository README.
And for transparency: APIs.io declares the extension and serves 20 skills. We built that, so it does not belong in a count of who in the market has adopted the spec.
Four out of 1,003 is small. It is also five weeks. The more telling number is the protocol: only 44 of the 1,450 endpoints that answered negotiate the current 2026-07-28 revision. Most are on 2025-11-25 (615) or still on 2024-11-05 (544). The extension that is spreading fastest is MCP Apps, declared by 45 endpoints, and only two declare Tasks.
Skills over MCP, without the spec
The more interesting finding is how many companies already decided skills belong on their MCP server and built their own way to serve them. Most of these predate the extension, and every one of them is a tool, not a resource, which means the client has to know the tool exists and what it is called.
Skills that teach the agent the product:
Amazon Web Services. The AWS MCP server has an aws___retrieve_skill tool that returns a skill’s SKILL.md, or a named file from it. You search the documentation first and pass along the skill name it returns. The same server shows up across eight of AWS’s service listings in our catalog.
Timescale (TigerData). A view_skill tool whose description lists all 11 skills inline: Postgres and PostGIS table design, finding hypertable candidates, migrating to hypertables, pgvector semantic search, hybrid BM25 search, zero-downtime schema migrations, schema exploration, and TimescaleDB hyperfunctions. A good catalog served in a non-standard way. It is one change away from the spec.
Daloopa. list_skills and get_skill serve investing workflows: structured analysis, valuation and deliverables, with the caller’s inputs substituted into the instructions it returns.
MyBotsPro. list_skills and get_skill serve the bundled Mira playbooks for UGC, product, ads and cinematic generation. get_skill returns a SKILL.md router first and individual sections on request, which is progressive disclosure built by hand.
Jentic. It points agents to a skill://onboard-jentic-one resource for the move to its self-hosted Jentic One, the right URI scheme, but it does not declare the extension.
Skills that act:
Browser Use. list_skills and execute_skill. Here a skill is a recorded automation that runs in milliseconds without a browser, and the tool description tells the agent to check for a skill before falling back to a full browser task. Same word, different idea, because these skills run instead of instructing.
Skills the customer brings:
Anthropic. The Claude platform’s MCP surface has list_skills and create_skill for managing a workspace’s custom Agent Skills.
Cequence. A Skill Registry in its AI gateway, with tools to create, list and fetch skills, next to the DLP policies it attaches to agents.
Fundamental Research Labs. list_skills across default, personal and team skills.
Jedify. load_skill fetches a markdown playbook that a user of the account wrote for the Jedify agent, after contextualize lists what is available.
Unisson. list_skills lists reusable skills available to its agents.
Skills as the product:
Wato. The fullest lifecycle I found: list published skills, fetch one as Markdown, fetch a bundled script or reference by path, save a draft, publish, and distill a conversation’s connector actions into a new skill.
Skillsync. Read, install, list and publish skills, for you or the current project.
Skills Directory. Search, download a skill ZIP, read a skill’s security grade and findings, and scan the skill you are writing.
Knostic. Search a catalog of agent skills with scan status, and trigger an on-demand security scan of a skill by repository.
TARX. Discover and list TARX skills, with private and local skills held back for a local runtime.
lvlltd. A paid skill catalog: search and preview for free, quote the price over x402, and get sealed files and SKILL.md install paths after purchase.
That is seventeen companies serving skills through their own tools, against four through the spec. I left out a few that matched on the word: Cognism, Nobueno, Voygr and Workerbase have list_skills tools, but for them a skill is a person’s job skill or a call intent, not an Agent Skill.
What I take from it
The demand was there before the spec. Companies were already putting skills on their MCP servers, and they each invented a tool with a slightly different name and a slightly different shape. That is exactly the problem a standard exists to fix. An agent that has learned skills/list can find Glean’s skills, Hugging Face’s and BestPrice’s without being told a tool name. An agent that meets Timescale, Daloopa and AWS has to read three tool descriptions to learn three conventions.
The companies doing the teaching-the-product kind are the easy conversions, because the content is already a SKILL.md and they would only need to change how it is served. The marketplaces and registries are harder and more interesting, since the spec covers serving skills, and not buying, scanning, grading or publishing them.
We will start recording the extension in each provider’s MCP profile, and it is a strong candidate for the Agent Readiness checks in the Kin Score. If you serve skills over MCP and I missed you, or you are behind authentication and want to be counted, tell me and I will probe again.
https://apievangelist.com/2026/10/21/four-companies-serve-skills-over-mcp-the-way-the-spec-says/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/four-companies-serve-skills-over-mcp-the-way-the-spec-says.png
#companiesserve #serveskills #fourcompanies #skillsextension #huggingface #protocol #python #agent #modelcontext #uri
#rss #feeds #linksharing #qwibbit

2026-10-21 14:56:07 GMT

Healthcare: The Shape Of The Answer
Yesterday I wrote about DeepInfer and the shape of the answer, and how batch-invariant inference, deterministic sampling and schema-constrained output together make valid JSON table stakes and push the real work back onto agreeing on the shape. Healthcare is the industry I want to look at first, because it is the one that has done the most work writing its shapes down.
The answer this industry needs
Healthcare runs on paper that isn’t paper anymore. A referral arrives as a fax. A clinical note is a block of dictated text. A prior authorization request is assembled by someone reading a chart and retyping it into a payer portal. The business outcome is almost always the same sentence: turn this document into valid FHIR resources a server will accept.
That means a Patient, an Encounter, the Observations and Conditions in the note, the MedicationRequest the clinician wrote, and when money is involved, a Claim. Not a summary of those things. The resources themselves, in a shape an EHR, a payer, or a data platform can take in without a human retyping them.
The shape is already written down
HL7 has been writing these shapes down for more than a decade. The FHIR R4 resource list defines MedicationRequest, Claim, Patient, Encounter, Observation and Condition, each with a StructureDefinition that is machine-readable. In the United States, the US Core Implementation Guide narrows those base resources into profiles. It is at version 9.0.0, STU 9, based on R4, and it describes itself as establishing “the floor” for US interoperability, including pages on writing clinical notes and vital signs. SMART App Launch covers who is allowed to read and write, and Bulk Data Access covers moving whole populations instead of one record.
The payer side is written down too. The Da Vinci Prior Authorization Support guide (v2.2.1, STU 2, on R4) defines a variant of the FHIR Claim $submit operation. The input is one Bundle containing a single Claim plus its referenced resources. The output is a Bundle with a single ClaimResponse, or an OperationOutcome. The guide is explicit that it supports mapping to the X12 278 transaction, and equally explicit that the X12 mapping itself is published by X12 under its own licensing, not by HL7.
So the shape of a prior authorization request is a Bundle. The shape of a medication order is a MedicationRequest profiled by US Core. This is about as close to a ready-made constraint for a decoder as any industry has.
What the catalog holds
The APIs.io standards page lists the providers whose own APIs.json carries each standard as a tag. That is their statement, not a measurement. HL7 FHIR is carried by 169 providers. SMART on FHIR by 44. US Core by 11. Da Vinci by 5. FHIR Bulk Data Access by 2. The API Evangelist standards catalog has its own FHIR profile.
Two Market-layer cohorts cover this ground. The Healthcare (FHIR) market has 24 providers, all scored, with a mean Kin Score of 70.6. Elation Health leads the clinical side at 79.4, with DrChrono at 77.5, Paubox at 77.0, Flexpa at 72.2 and Medplum at 71.7. Gainsight sits at the top of the cohort at 82.1, which tells you the cohort includes vendors serving healthcare, not only clinical systems. The medtech cohort, built from certified health IT developers and FDA AI-enabled device makers, is 47 providers with a mean of 40.7. Epic leads it at 62.5, with Medblocks at 62.1. The bottom of that cohort is the device makers, several of them under 10.
Agent readiness is the gap. In the healthcare cohort the highest is Paubox at 63.3 and Medplum at 54.9, and most sit between 30 and 45. In medtech, Medblocks is the one provider above 60, at 64.4.
Across the 71 providers in both cohorts, here is what their repos hold:
47 have OpenAPI
34 have AsyncAPI
27 have JSON Schema
25 have a vocabulary
17 have examples
7 have JSON Structure
7 have Arazzo workflows
Fifteen of them have OpenAPI that names FHIR clinical resources directly. Oracle Health has per-resource contracts for Patient, Encounter, Observation, Condition and MedicationRequest. Canvas Medical and ModMed publish a FHIR spec that we split into one contract per resource, so the per-resource files are our work on top of their published shape. Some of the Oracle Health files carry an x-generated-by marker, meaning they were written from Oracle’s documentation by our pipeline rather than downloaded as a spec, and for many of the rest the authorship isn’t recorded. Epic’s repo has a fhir/ folder rather than an OpenAPI one. Only five providers in the two cohorts have contracts that reference Claim, ClaimResponse or ExplanationOfBenefit: athenahealth, Canvas Medical, Independence Blue Cross, Medplum and Flexpa.
What determinism changes here
Healthcare has three problems that deterministic, constrained inference speaks to directly.
The first is audit. A prior authorization decision, or a claim, has to be explainable after the fact. If the same fax produces a different Bundle on a re-run because of what else happened to be in the batch, you cannot reconstruct what the system did. Batch-invariant, deterministic output means the same document produces the same resources, and you can replay it.
The second is safety. A MedicationRequest with a free-text dose that “looks right” is a liability. Constraining output to the US Core profile, with value sets as enums, means the model can’t invent a code that isn’t in the value set. It can still pick the wrong one, which is why the check after generation still matters, but it can’t produce something the server will silently mangle.
The third is volume. Payers and health systems process documents by the million. Reconciliation at that volume depends on the answer being stable, so that a diff between two runs is a real change and not sampling noise.
Where it falls short
The base resources are well covered. The money side is not. Five providers out of 71 have a Claim-shaped contract I can find in the catalog, and Da Vinci is carried as a tag by five providers across the whole catalog. The guide that defines prior authorization as a FHIR Bundle depends on an X12 mapping that is not openly published, so the most valuable shape in this industry is only partly open.
Much of the FHIR surface in the catalog is also our work rather than the provider’s. Per-resource contracts that we split, or generated from docs, are useful, but they are not the same as a provider publishing the profile it actually enforces. A generic FHIR R4 schema is too loose to constrain a decoder well. What you want is each server’s CapabilityStatement and profiles, and those are rarely in the catalog as artifacts. The device makers in the medtech cohort are barely present at all.
The shape was the hard part
Healthcare already did the boring work. HL7 wrote the resources, US Core wrote the floor, Da Vinci wrote the payer Bundle. What’s missing is providers publishing the exact profiles they enforce, as artifacts a decoder can load. Do that, and turning a fax into a valid Bundle stops being a project and becomes a call that returns the same answer every time.
https://apievangelist.com/2026/10/21/healthcare-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/healthcare-the-shape-of-the-answer.png
#shape #fhir #answer #healthcare #claim #bulkdata #dataaccess #priorauthorization #bundle #core
#rss #feeds #linksharing #qwibbit

2026-10-20 20:37:19 GMT

A Listing Is Not A Certification
When you build a market layer out of public registers, you quickly find two very different kinds of entry, and the Kin Score has to treat them differently.
Two kinds of entry
The first kind is a listing. The CNCF landscape lists 2,431 projects and members. The OpenSSF landscape lists its members. AgGateway publishes its members. A listing says a company takes part. It is real, and it is cheap.
The second kind is a certification. The CNCF’s Certified Kubernetes program publishes 1,579 conformance submissions from 185 vendors, product by product and version by version. ODVA only lists vendors whose products passed its conformance testing. OPC Foundation certifies products against OPC UA. FedRAMP authorizes cloud services at specific impact levels. Peppol certifies access points. BACnet Testing Laboratories lists tested device profiles. A certification says someone outside the company checked.
Both belong in a market. They don’t deserve the same weight.
How the Kin Score separates them
A listing alone puts a provider in the “standard” position, at a modest depth. That stays true even when it feels generous. In cloud native, 52 providers reached standard on a single landscape listing, Helm, Linkerd, and K3s among them. We decided to keep them there. The position says they participate. Depth is what says how much.
Certification adds depth, and each register gets its own ceiling. We set every ceiling the same way, from the data: the widest current vendor in that register. FedRAMP caps at three authorized impact levels. Certified Kubernetes caps at three product types. Peppol caps at two, access point and SMP. GS1 GDSN caps at two, item and price. BACnet caps at eighteen, because Siemens holds eighteen listed device profiles. Lapsed certifications count for nothing.
The result is that depth now separates the two kinds of provider within the same position. Certified Kubernetes platforms read between 35 and 53. A landscape listing alone reads 17.2.
The bug that hid it
We found something embarrassing on the way there. A certified register writes two records about a vendor from the same piece of evidence: a participation edge, and a report-only “compatible” edge recording which standard it speaks. Our depth code looked the evidence up and kept the last record it saw, which was the compatible one. Then it skipped it, because compatible edges are report-only.
So every certified vendor had been losing its certification. 1WorldSync, Salsify, and Siemens read 17.2, the same as a company that only joined a member list. Rockwell and KUKA had no depth at all.
With the fix, 1WorldSync, Salsify, and Siemens read 40.9. Rockwell reads 23.6 and KUKA 19.4. Trustwell, which is a GS1 solution partner without a certified data pool, stays at 17.2, which is exactly right.
I’m sharing that one because it is the kind of mistake that hides in any scoring system. Nobody notices a score that is wrong in a plausible direction. The way we caught it was by asking why two companies with obviously different evidence had identical numbers.
Why the distinction matters for agents
An agent choosing a provider for a regulated job doesn’t need to know who joined an association. It needs to know who passed. The difference between a listing and a certification is the difference between “this company says it supports the standard” and “someone checked.” The Market layer now carries that difference all the way through to the score, and every certified entry links back to the register that issued it.
https://apievangelist.com/2026/10/20/a-listing-is-not-a-certification/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/a-listing-is-not-a-certification.png
#listing #certification #certified #two #depth #kinscore #kubernetes #siemens #cncf #opc
#rss #feeds #linksharing #qwibbit

2026-10-20 20:11:41 GMT

DeepInfer And The Shape Of The Answer
DeepSeek open-sourced DeepInfer last week, the inference framework that powers its own large-scale production services. It is Apache 2.0 licensed, it runs DeepSeek-V4.1-Flash on NVIDIA’s newest GPUs and Huawei’s Ascend NPUs, and most of the README is the kind of thing inference engineers will spend the next month arguing about: optimized kernels, expert parallelism, draft-token decoding with confidence-scheduled verification, asynchronous scheduling. It’s significant on those terms alone.
But the part I keep coming back to is three lines further down the feature list. DeepInfer supports batch-invariant inference, so a request returns the same result no matter what else is in the batch with it. It supports deterministic sampling, so identical input tokens and sampling parameters produce identical output. And it supports structured outputs, constraining generation to a JSON schema, a regular expression, or an EBNF grammar.
Put those three together and you have something the API world has been waiting for from models: an answer you can describe ahead of time, that comes back in that shape every time, and that comes back the same way twice.
Beyond decision models
Last week I wrote that decision models agreed on the questions, not the contract. Eleven providers now ask the same three kinds of question, yes or no, pick one, and score, and every answer comes back with probabilities. The questions converged. The URL didn’t, and neither did the contract.
Decision models are one narrow shape: a choice and a confidence. What DeepInfer puts in the open is the machinery to make any shape the answer. A claim that comes back as the fields an insurer’s adjudication system expects. A shipment exception as the carrier’s own status codes. An invoice as the line items a tax engine needs. A clinical note as the resources a FHIR server will accept. And because the sampling is deterministic and the batching doesn’t change the result, the same input gets the same structured answer on Tuesday and on Friday, which is the property every downstream system was built to assume.
I think this is how we get beyond a generic decision API and into a myriad of industry versions of it, each one shaped around a specific business outcome rather than a generic yes, no, or score.
Where do the shapes come from?
This is the question that matters, and it is the one I have been working on for a while without quite calling it this. A JSON schema constraint is only as good as the schema. A grammar is only as good as the grammar. If every team writes its own shapes from scratch, we get the decision model problem again: everyone agrees on the idea and nobody agrees on the contract.
The shapes already exist. They are in the APIs your business and your industry already depend on, and that is a lot of what APIs.io has been harvesting:
Schemas — the JSON Schema each provider publishes for the objects its APIs accept and return. A customer, an order, a claim, a payment. Hand one to a constrained decoder and the model can only answer in a shape the receiving API will accept.
JSON Structure — more than 47,000 type definitions with the precision JSON Schema leaves loose: decimals with scale, dates, money, unions.
Vocabularies — the controlled terms an industry has settled on, which become the enums in a schema or the terminals in a grammar. The model can’t invent a status code that doesn’t exist.
OpenAPI and AsyncAPI — the request and response bodies of real operations and real events. The target shape for “produce the payload for this call.”
Examples — more than 57,000 real request and response examples, the closest thing to ground truth for what a valid answer looks like in practice.
Rules — Spectral rulesets that check what a schema alone can’t, run against the output after it is generated.
Overlays — the layer where you add the agent-facing constraints to a provider’s contract without forking it.
Arazzo workflows — the sequence. A structured answer is usually one step in a chain, and the workflow says what shape each step has to produce for the next one to work.
Standards — the profiles of what an industry actually implements, from the OpenAI interface to SCIM, graded by adoption. A standard’s core tier is a shape a whole market already agreed on.
Business capabilities and markets — which tells you, for a given business outcome, which providers’ shapes are the ones that matter.
Agentic access — what an operation costs, whether it can be undone, and where a human has to approve it. Shapes for the guardrails, not just the data.
That is the inference harness I think this release makes possible. Pick the business outcome. Find the capability and the providers who serve it. Take their schemas, vocabularies and examples as the constraint. Take the workflow as the sequence and the rules as the check. Run it on an engine where the output is constrained, deterministic and batch-invariant. What you get back isn’t text you have to parse and hope about. It’s a payload that fits the API on the other side, and it fits the same way every time.
The contract was always the point
Most of the conversation about structured outputs so far has been about getting valid JSON out of a model. That was the hard part a year ago. With DeepInfer in the open, valid JSON is table stakes. The hard part now is the same hard part it has always been in the API world: agreeing on the shape. The decision model providers showed what happens when you don’t.
The industries that will get the most out of this are the ones that already wrote their shapes down, in OpenAPI, JSON Schema, vocabularies and standards. The rest will be writing prompts that describe a shape in prose and hoping the model guesses. Deterministic inference rewards the people who did the boring work of describing their business precisely, and that has always been the case for APIs.
https://apievangelist.com/2026/10/20/deepinfer-and-the-shape-of-the-answer/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/deepinfer-and-the-shape-of-the-answer.png
#answer #jsonschema #deepinfer #shape #decision #apis
#rss #feeds #linksharing #qwibbit

2026-10-20 19:47:42 GMT

The Incumbent And The Challenger: NCR Voyix And Lightspeed
I hear the same thing in almost every enterprise conversation I have. We can’t have a public developer portal. We can’t publish our API documentation. Our customers are big, our deals are negotiated, our partners sign agreements first, and nothing about our business works out in the open. I understand where it comes from. But I want to start answering it with something other than my opinion, because in most markets the answer is sitting right next to you: you can, because your competition is already doing it, and in an agentic world they are coming for your business.
So this is the first in a recurring series. Each one takes a segment of the market, finds the established leader with a middling or low Kin Score, finds a challenger who may not be as big but publishes a lot more, and puts them side by side. Not to embarrass anyone. To show what is already possible in their own market.
Restaurant point of sale
The first one is restaurant point of sale, from the restaurant POS market in the APIs.io Market layer.
NCR Voyix is the incumbent. Its Aloha point-of-sale system has been on restaurant counters for decades, and NCR Voyix runs digital commerce for retailers and restaurants around the world. Lightspeed is the challenger: a cloud commerce platform for retail and restaurants, smaller, younger, and built online.
NCR Voyix
Lightspeed
Kin Score
27.5, thin
83.8, exemplar
Agent readiness
22.9, agent-aware
42.6, agent-ready
Discoverability
78.6
81.7
Contract quality
25.9
74.7
Contract governance
27.3
22.0
Operational transparency
7.9
92.1
Developer ergonomics
36.9
85.1
Access clarity
5.3
92.1
OpenAPI descriptions in the catalog
7
54
What the difference actually is
NCR Voyix is not dark. It has a developer portal and documentation, seven APIs described in OpenAPI, from catalog and orders to sites and selling, and it scores well on discoverability. If your story is “we can’t have a public portal,” NCR Voyix already proves you can, and so does its score. Being findable is the one facet where the incumbent holds its own.
The gap is everything after you find it. NCR Voyix scores 7.9 on operational transparency and 5.3 on access clarity. There is no status page, no pricing, no sign-up path and no change log I can point an agent at. A developer, or an agent acting for one, can see that the APIs exist, and then has to stop and talk to somebody.
Lightspeed is the opposite. Fifty-four OpenAPI descriptions across retail, restaurant, e-commerce and golf. Public pricing, a status page, a sign-up path, support, SDKs, OAuth scopes, an error catalog, an llms.txt, an AsyncAPI description for its events, and an MCP server served through its documentation platform. On the agent side it documents idempotency, reversibility and delegated access, and its errors are a stable envelope an agent can branch on. It is gated just short of agent-native.
Neither of them is perfect. Lightspeed scores lower than NCR Voyix on contract governance, because neither publishes much in the way of rules or conformance. But one of them has done the work to let someone, or something, go from finding the API to using it without a meeting, and one hasn’t.
Why this matters now
A restaurant group choosing a point of sale used to do it through a sales cycle, and the API was a line item in the RFP. That is changing. The integrators, the delivery and loyalty platforms, and increasingly the agents doing the research on someone’s behalf, start from what they can read. An agent asked to find a POS that can sync menus, pull orders and post payments to an accounting system will find the one whose contract, pricing, limits and status it can read without asking. In that world, the gap between 27.5 and 83.8 is not a score. It’s a shortlist.
None of what Lightspeed publishes is exotic. It is a portal, an OpenAPI per product, a pricing page, a status page, a sign-up, and a few machine-readable files that tell an agent the rules. None of it requires giving away the business. It requires deciding that the interface to your business is something you publish rather than something you negotiate.
Go look for yourself
Both companies have full profiles, with every artifact we found and where we found it:
NCR Voyix: APIs.io · API Evangelist · GitHub
Lightspeed: APIs.io · API Evangelist · GitHub
If you are NCR Voyix, or any incumbent who sees themselves in this, the GitHub repository is open and every gap in the score points at the artifact that would close it. If you think we got something wrong, tell me. And if you are the one telling your team you can’t have a public portal, look at who in your market already does.
https://apievangelist.com/2026/10/20/the-incumbent-and-the-challenger-ncr-voyix-and-lightspeed/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-incumbent-and-the-challenger-ncr-voyix-and-lightspeed.png
#ncrvoyix #lightspeed #challenger #incumbent #agent #restaurant #kinscore #market #developer #access
#rss #feeds #linksharing #qwibbit

2026-10-20 19:20:10 GMT

Three Hundred Eighty-Nine Agent Cards Are Live, And We Are Not Counting Ours
We built an AI agents market for the Kin Score this week, and it is the first market where the strongest evidence is something a provider publishes about itself.
What we read
The A2A protocol lets a provider publish an agent card at a well-known address on its own domain, describing the agent, what it can do, and how to talk to it. The catalog already tracked 487 of these. We re-probed every one of them live.
389 are live.
62 are “flavored,” meaning they exist but drift from the spec.
27 are gone.
7 aren’t agent cards at all.
Of the 371 we could tie to a provider, 276 conform to the spec. We also read the a2aregistry.org register, 566 listings across 304 hosts. One host alone accounts for 98 of those listings, which is why we count one fact per host, never the listings.
A card on your own domain is a declaration
The Kin Score rule for markets is that declaration is the provider’s responsibility. An agent card served from a provider’s own domain is about the cleanest declaration there is. Nobody else can put it there.
So we decided that once we have four weekly snapshots, a provider’s own agent card will count as its own declaration in the market. The first snapshot was October 15. The fourth lands November 2. When that happens, most of the 122 undeclared providers in this cohort move to declared. That would be the largest single shift any market has produced so far.
Registry listings are different. Anyone can list an agent in a registry. Those stay report-only, the same way we treat MCP registry listings.
The cards we didn’t count
Here is the part I want to be clear about. API Evangelist and APIs.io host agent cards ourselves, for companies like Oracle, SAP, MuleSoft, SendGrid, and Splunk. We built those to show what a well-formed card looks like for those APIs.
We held all thirteen of them, and our own, out of the market. Crediting a provider for a card we wrote would be crediting our own work. A provider gets credit when it publishes its own card, on its own domain, and not before.
We held other cards back too:
About 22 docs-platform cards with generic names like “Developer Documentation,” where the card describes the docs host rather than the company.
Cards served from someone else’s domain, or naming a different product than the company that serves them.
Cards on shared hosting platforms, where the domain proves nothing about who wrote it.
What it says about the frontier
Two things stood out. First, conformance is higher than I expected for a protocol this young: three quarters of the linked cards follow the spec. Second, the highest-scoring API companies in the cohort mostly don’t publish a card yet. The early adopters are agent-native companies, not established API providers.
That is the frontier pattern we keep seeing. The shape gets agreed on by new entrants first, and the established providers follow once someone can measure the difference. We’ll be watching the weekly snapshots to see how fast that happens.
https://apievangelist.com/2026/10/20/three-hundred-eighty-nine-agent-cards-are-live-and-we-are-not-counting-ours/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/three-hundred-eighty-nine-agent-cards-are-live-and-we-are-not-counting-ours.png
#agent #cards #kinscore #api #first
#rss #feeds #linksharing #qwibbit

2026-10-20 18:53:19 GMT

Five Thousand Official SDKs, And Nine Thousand That Are Not
One of the markets we built this week isn’t an industry at all. It cuts across the whole catalog: which API providers publish their own official SDKs.
How we measured it
We started from the SDK links the catalog already stores for each provider and checked every one against the package registry it lives on: npm, PyPI, the Go module proxy, Maven Central, NuGet, RubyGems, and crates.io. That was 15,094 candidate packages across 3,802 providers.
A package only counts as official when two things are true. Its homepage or repository lives on the provider’s own domain or the provider’s own GitHub organization. And the publisher, by email domain or organization, matches the provider too. Both legs, every time.
What we found
5,008 official SDK packages across 1,808 providers.
Registry
Providers with an official SDK
npm
1,238
PyPI
523
Go
386
Maven
226
RubyGems
102
NuGet
89
crates.io
26
JavaScript is still the default developer surface by a wide margin. Python is the clear second, which matches what agents are written in. Rust is barely on the board.
The more interesting number is the other one. Roughly 8,900 of the packages that look like a provider’s SDK aren’t official. They are community wrappers, forks, abandoned experiments, and in a few cases utility libraries that just borrowed a name. One of our own spot checks caught a fork of a color library being counted as an SDK, which is how we ended up widening the filter.
Why this belongs in the Kin Score
Agents don’t read documentation the way people do. They install packages. When a coding agent is asked to integrate with an API, the first thing it usually does is search a package registry for the provider’s name, and it takes whatever comes back. If the official SDK isn’t clearly the provider’s, the agent may well pick the wrapper with the better README.
That makes officiality an agent-readiness question, not just a developer experience nicety. A provider whose SDK homepage points at its own domain, and whose packages are published under its own organization, is telling an agent which package to trust. A provider whose ecosystem is mostly community packages is leaving that decision to whoever named their package first.
We also record staleness. An official SDK with no release in 24 months is marked lapsed. Plenty of providers have an official package that hasn’t moved since before their current API version shipped.
What providers can do
The fix is small and entirely in the provider’s hands:
Point every SDK’s homepage and repository at your own domain or GitHub organization.
Publish under an organization or email domain that matches your company.
Link your SDKs from your developer portal and your APIs.json.
Ship releases, or mark the package deprecated when you stop.
These SDK edges don’t move market positions today. They sit alongside them as a distribution signal. But they are now part of what the Kin Score knows about a provider, and they are one of the clearest signals an agent has.
https://apievangelist.com/2026/10/20/five-thousand-official-sdks-and-nine-thousand-that-are-not/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/five-thousand-official-sdks-and-nine-thousand-that-are-not.png
#sdk #kinscore #api #mavencentral #registry
#rss #feeds #linksharing #qwibbit

2026-10-19 20:48:18 GMT

A Competitive Landscape Harness
I am working with an API provider right now on making their platform ready for agents, including standing up their own MCP server. The most useful thing I have done for them so far isn’t designing anything. It’s measuring what everyone else in their market already built, and turning that into a harness for everything we build next. I am calling it a competitive landscape harness, and I think it is one of the more practical things to come out of the catalog work.
The idea is simple. Before you design a new API, iterate on an existing one, ship an MCP server, or rework your developer presence, you take the artifacts your competitors and your industry have already published and use them as the mold. Not to copy them. To know, decision by decision, what the market has settled on, where it is split, and where nobody has gone yet.
Same bar for everyone
The first step is to profile the whole competitive set the same way, on the same day, with the same pipeline. Their OpenAPI, their MCP servers, their agent cards and server cards, their OAuth and protected resource metadata, their skills, their plans and rate limits, their sandboxes, their onboarding. All of it lands in the APIs.io catalog and gets scored on the Kin Score and agent readiness. For this engagement that was eight direct competitors plus the provider itself, re-profiled on one afternoon so the numbers were comparable.
The scores matter less than you would think. They tell you who is ahead, but the useful output is the inventory underneath them: what each company actually shipped, read from live server cards, initialize responses, metadata documents, public repositories and docs, rather than from press releases.
Turn the inventory into design decisions
The second step is to read that inventory feature by feature and write each difference down as a decision. Hosting, authentication to the server, tool design, discovery, skills, sandbox access, registration, scopes, observability. For each one: what did the rivals choose, and what should we do. Copy it, beat it, or deliberately decline it.
That exercise produced a list of eleven decisions, and a few of them are worth sharing because they will apply to almost anyone:
Generic tools or decision tools. Some competitors converged on three generic tools: search the endpoints, get a schema, invoke. That keeps context small. Others built task-shaped tools that match a job. The answer for us was both, in layers.
Discoverable before clever. The best servers in the set answer initialize and tools/list without credentials, publish a server card with instructions, and return a 401 that tells the agent how to get a key. Ours said “Authorization required” and nothing else. That was the cheapest fix in the whole document.
A sandbox an agent can hit with no human. Two rivals let an agent prove an integration works before a person is involved. Ours had a trial that refused every call until a human verified something. The largest usability gap we found, and already solved by others.
Scoped credentials for agents. Three competitors let a customer hand an agent a credential that can read but not write. An all-or-nothing key is the product shape of a decision about whether to stand up an OAuth issuer.
Skills with a CANNOT section. The strongest skills catalogue in the set types every skill and ends each one with what the agent cannot do. That is guidance an agent actually uses.
Then the decisions get sorted into two columns: where we would be catching up, and where we would be first in the market. That second column is the one executives care about, because it is where the work turns into a position.
Standards are the mold
The third step is what keeps this from becoming a copy exercise. Wherever a decision can be expressed as an existing standard, we use the standard. OpenAPI for the contract. Arazzo for the workflows. Overlays for the agent-facing layer on a contract we don’t want to fork. An MCP server card for discovery, RFC 9728 protected resource metadata for auth, Agent Skills for operating instructions, APIs.json and the well-known API catalog for finding all of it. And an agentic access contract that says, per operation, what it costs, whether it can be undone, and where a human has to be in the loop.
The competitors show you what the market expects. The standards give you a shape that every client, marketplace and agent framework already knows how to read. Between the two you are not inventing an interface, you are filling in a mold the market and the standards bodies have already poured.
One harness, four kinds of work
The same harness drives every kind of work on the table:
A new API. Start from the operations and schemas the market already exposes for the capability, so the agent that knows the category already knows you.
Iterating an existing API. The gaps are concrete: idempotency on the writes, a typed error envelope, rate-limit headers, the things that separate agent-ready from agent-native, measured against peers who already ship them.
An MCP server. Tool design, discovery, auth, sandbox and observability decisions, each one benchmarked against what is live in the market today.
The presence and experience. Skills, onboarding, the server card, the docs an agent reads. Programmable and easy to use for an agent, and still recognisable to the humans the market already serves.
And because everything is profiled in the same catalog, the harness checks itself. Ship a change, re-profile, and see whether you moved relative to the market and not just relative to last month.
Why I think this matters
Most of what I see in the agent space right now is companies building in isolation. A press release, an MCP server shaped by whatever the vendor template produced, and no idea whether it matches what the rest of the market converged on. The artifacts to do better already exist. Your competitors have published them, and the standards bodies have defined the shapes. A competitive landscape harness is just the discipline of reading all of it before you build, and measuring against all of it after.
It is also the kind of work APIs.io makes possible at scale. The same harness I am running for one provider can be run for any market in the catalog. If you want to know what your market has already built, and where you could be first, that is a conversation I am happy to have.
https://apievangelist.com/2026/10/19/a-competitive-landscape-harness/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/a-competitive-landscape-harness.png
#landscapeharness #competitivelandscape #mcp #same #api #kinscore
#rss #feeds #linksharing #qwibbit

2026-10-19 20:23:43 GMT

Every Regulated Market Already Publishes Its Own Map
A week ago I said the Kin Score was getting a third dimension, the market. Since then we have taken it from four markets to eighty-six, and the most useful thing I learned along the way is not about any one industry. It is about where the map of a market actually lives.
In open markets, the map lives in marketplaces and workflows. Salesforce, Slack, Zoom, Shopify, and Zapier all publish who builds on them. In regulated markets, the map lives in registers. And it turns out almost every regulated market already publishes its own.
The registers are already there
Here is a partial list of what we read this week, all public, all machine-readable or close to it:
FedRAMP publishes every authorized cloud provider and its impact levels. 425 packages from 342 providers.
The SEC publishes every registered investment adviser, and each adviser files its own website on Form ADV. 24,011 advisers.
ICANN publishes every accredited domain registrar, with a URL. 3,324 accreditations.
The Monetary Authority of Singapore publishes its financial institutions directory. Bank Indonesia publishes its payment licences as a spreadsheet.
The FAA publishes approved LAANC drone service suppliers and every accepted Remote ID declaration of compliance.
Mozilla’s CCADB publishes every certificate authority and which root stores trust it today.
Open Finance Brasil publishes every participant and every API resource it certified, with expiry dates.
Metrc publishes which software vendors are validated for cannabis track-and-trace, state by state.
The FDA publishes its list of AI-enabled medical devices. ONC publishes the FHIR endpoint lists that certified health IT developers are required to expose.
None of these were built for us. They were built so regulators, buyers, and auditors could answer the question of who is allowed to do what. That is exactly the question a market layer needs answered, and it is answered deterministically, by the market itself, with no model guessing.
What a register tells you, and what it doesn’t
A register entry is a fact, but it is a narrow one. Being on the SEC’s adviser list tells you a firm is registered. It doesn’t tell you the firm has an API, and it doesn’t tell you anything is integrated. So we hold to a few rules.
A listing is participation, not depth. A provider that appears in a register reads “standard” or “regulated” in its market, and its depth stays low until something deeper shows up.
Certification is depth. When a register certifies a product, like a FedRAMP impact level, a Kubernetes conformance result, or a validated Metrc integration, that is a different and stronger signal. Each register gets its own ceiling, set by the widest vendor actually in the data.
Domain, not name. We only link a register entry to a provider when the domain matches, and the name checks out. When a register only gives names, we can resolve a domain through Wikidata, but we label it, and the domain still has to pass the same check.
Fit matters. A register lists everyone it regulates, not everyone in the market. The EPA’s hazardous waste handler list is full of companies that only handle their own waste. A carbon market sweep that linked them would have been mostly wrong, so we now hold anyone who appears in a register outside their own business.
Self-filed registers need more care
One register taught us a hard lesson. FinCEN’s money services business list is self-filed, meaning anyone can submit a registration. When we looked closely, a cluster of filings from virtual-office addresses used the names of well-known banks, brokerages, and crypto companies, usually with every activity box ticked. A name lookup resolves those to the real company’s domain, the name check passes, and you have just credited a company with a registration it never filed.
We caught 46 of them by hand. The rule now is that a self-filed register also has to agree with the company’s registered country before we link anything. Any agent reading public registers needs that same skepticism. A register is only as good as who is allowed to write to it.
The gaps are findings too
Not every market gave up its map. The Gulf registers, SAMA in Saudi Arabia and the UAE’s Central Bank, wouldn’t answer our requests. Nutrition and sports data have no register at all. Leagues announce their official data partners in press releases. Those gaps are as telling as the registers. A market that doesn’t publish its own structure is a market where you can’t easily prove who belongs.
Eighty-six markets in, the pattern holds. Open markets integrate through workflows. Regulated markets integrate through standards. And regulated markets have already done half our work for us. They just haven’t connected their registers to the APIs.
https://apievangelist.com/2026/10/19/every-regulated-market-already-publishes-its-own-map/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/every-regulated-market-already-publishes-its-own-map.png
#marketalready #regulatedmarket #every #alreadypublishes #map #kinscore #domain #sec #api #formadv
#rss #feeds #linksharing #qwibbit

2026-10-19 19:59:29 GMT

The Brands Are Missing From Their Own Markets
One of the stranger results from building out the Market layer of the Kin Score is how often the biggest names in an industry don’t show up in its structure at all.
Consumer goods
We built a consumer goods market from GS1’s certified data pool list, GS1 US solution partners, and the SPS Commerce partner network. SPS Commerce moved up to gravity. 1WorldSync, Salsify, Trustwell, and Avery Dennison all moved into standard.
And every big consumer brand in the cohort, Procter & Gamble, Unilever, and the rest, is still undeclared.
That isn’t because the registers are wrong. GS1’s registers name the data pools and solution vendors that carry product data between brands and retailers. The brands publish through them. In consumer goods, the API belongs to the intermediary, not the brand. If you want to understand who is programmable in that market, you look at the pipes, not the products.
Agriculture
Agriculture told a similar story. AgGateway’s member list, the agrirouter solution finder, and Climate FieldView’s connected partners moved John Deere, CNH, AGCO, Granular, and xFarm into standard, and FieldView itself up to gravity.
But the providers at the top of the agriculture cohort by Kin Score, Barchart, DTN, farmOS, and ClimateAI, appear in none of those registers. Neither does any nutrition API. Open Food Facts, Spoonacular, FatSecret, and Nutritionix are the most usable food APIs we profile, and food has no register at all. The equipment makers declare their participation. The data businesses, the ones developers actually integrate with, don’t appear anywhere.
Industrial and robotics
Industrial was the starkest. OPC Foundation and ODVA conformance registers moved Siemens, Rockwell, KUKA, and Universal Robots into standard, with real certified products behind them. The API-first companies in the same cohort, Losant, Cumulocity, Viam, and the AWS IoT services, aren’t in any of those registers. Neither are ABB, FANUC, or Yaskawa.
Conformance and APIs are two different worlds in industrial. The hardware vendors prove they speak the protocol. The software vendors publish APIs. Almost nobody does both in a way a machine can read.
Weather, media, and the rest
It keeps happening:
Weather. No commercial weather API is a WMO WIS2 centre. Not Tomorrow.io, OpenWeatherMap, AccuWeather, or Visual Crossing. The public met services are on the register. The APIs developers use are not.
News. No news API in our cohort is a C2PA applicant. The content credentials work is happening at Adobe, OpenAI, Getty, and Cloudinary.
Sports. Sportradar, Genius Sports, and Stats Perform are the companies everyone integrates with for sports data. Leagues name them as official partners in press releases, never in a list a machine can read.
Why this matters
The Kin Score rule is that declaration is the provider’s responsibility. If a provider doesn’t articulate its integrations, partnerships, and participation in a form we can read, it reads “undeclared.” That is their problem, not ours.
What this week showed is that the undeclared column isn’t random. It clusters in a predictable place: the companies whose value is the data itself, sitting next to the companies whose value is moving it. The market structure is published by the pipes. The brands and the data providers are relying on everyone already knowing who they are.
That works until an agent has to decide who to call, and the only thing it can read is the register.
https://apievangelist.com/2026/10/19/the-brands-are-missing-from-their-own-markets/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-brands-are-missing-from-their-own-markets.png
#spscommerce #kinscore #api #consumer #agriculture #averydennison #food #industrial #weather
#rss #feeds #linksharing #qwibbit

2026-10-19 19:34:27 GMT

The Harness That Works Is A Contract
Naresh Jain published Are Harnesses Worth the Cost? on martinfowler.com last week, and it is the most useful thing I have read about coding agents this year. It’s useful because it measures something, not because it argues something.
He had agents build the same backend-for-frontend service ten times with a harness and ten times without, using a frontier model and a cost-optimized one. A separate suite of 178 acceptance tests that the agents never saw judged every run. The frontier model passed 10 out of 10 either way, and the harness made it about seven times more expensive. The cheaper model passed 3 out of 10 without the harness and 10 out of 10 with it. Harnessed, it cost about a third less per run than the frontier model did on its own.
Where the agents failed
The failures are the part I keep coming back to. The unharnessed runs were mostly right, passing at least 144 of the 178 checks. What they got wrong was the edges: a timeout returning a 503 instead of a 202 with a monitor link, a Kafka message delivered with an extra type header and a null where the schema said otherwise, a 415 where the brief asked for a 400, an environment variable named ORDER_API_API_KEY when the integration expected ORDER_API_KEY.
None of these are reasoning failures. They are contract failures, at the seams where one system meets another. Naresh calls the harness “executable attention.” The requirement was in the brief all along. It just lost its grip on the agent partway through the work, and a failing check put it back in front of it.
Most harnesses are not built like this
When people talk about agent harnesses today, they mostly mean an AGENTS.md file, some skills, a set of MCP tools, linters, type checkers, hooks, and increasingly another model acting as a judge or reviewer. All of that is useful, but it is generic. A linter knows what good Java looks like. It does not know that the Order API returns a 202 when creation is deferred.
Naresh’s harness is something different. Its core is an OpenAPI contract for the service being built, an OpenAPI contract for the downstream Order API, an AsyncAPI contract for the Kafka events, and request and response examples covering timeouts, malformed payloads, filter violations and retries. Mocks generated from those contracts make the downstream failures real enough to test against. Tests check conformance, response values and side effects. And one step I want everyone to notice runs before any test: it validates that every example actually conforms to its contract, so the harness cannot contradict itself.
The checks that decide pass or fail are not a model’s opinion. They are deterministic and they come from the contract. The agent was told to fix the implementation, never to weaken the expectations.
Spec-driven development is the other half
The spec-driven development crowd is closing in on the same idea from the other direction. GitHub’s Spec Kit takes you from specification to plan to tasks to implementation. Kiro builds a three-phase spec workflow into the IDE. Tessl goes further and treats the spec as the real source and the code as something generated from it. These are good tools, and they get people writing down what they want before an agent writes code.
Most of those specs, though, are prose: requirements, user stories, plans written in Markdown. Prose is what an agent reads, and it is also what an agent stops paying attention to forty minutes into a run. Naresh’s results show that what keeps a cheaper model honest is a spec that a machine can execute against. A requirements document only tells the agent what you wanted, while a contract will fail the build when the implementation doesn’t match.
The contract is the part nobody hands you
The detail in the experiment that matters most to me is one Naresh is upfront about. He wrote the contracts himself. The brief was unusually detailed, and the Order API spec came from the same person who designed the experiment.
That isn’t how integration works in the real world. Most of the seams an agent has to get right belong to someone else: a payments provider, a messaging API, a CRM, a shipping carrier. Those are exactly the places where his agents dropped requirements, and they are the places where no team has time to hand-write an OpenAPI contract and a set of examples before letting an agent loose.
That’s what we are working on at APIs.io. We are building out the contracts, examples, and supporting artifacts for public APIs, and attaching provenance that tells you where each one came from. If you want to point a cheaper model at a third-party integration and wrap it in a harness, the harness has to start from the provider’s contract. Ideally that contract is published by the provider, and otherwise it is clearly marked as derived from their docs and validated before anyone trusts it.
Provenance matters here because of a caveat Naresh states plainly: checks can only enforce the expectations humans encode. A harness built on a wrong contract will be confidently wrong. We have pulled fabricated specs out of our own catalog, and we gate the contracts we generate from documentation so they can’t pass themselves off as the provider’s own. A contract catalog is only worth building a harness on if you can tell which contracts are real.
Our own numbers point the same way
We see a version of this inside our own enrichment pipeline at APIs.io, which profiles tens of thousands of API providers. When we audited it, 20 of its 41 steps turned out to need no model at all, only scripts and schemas. When we ran Claude head-to-head against a local open-weight model on the same top providers, Claude won or tied every time, but every large margin traced back to a deterministic probe that had failed, not to the model’s reasoning. When we gave the local model a better set of derived artifacts to work from, its scores went up, and fixing the scripts moved its scores more than changing the model did.
Naresh’s conclusion is that model capability decides when you run the checks, not whether you need them. Cheaper models need them throughout, and frontier models need them at least once, as a final gate. I’d add one thing from where I sit: either way, someone has to write the contract. For the APIs you build, that’s you. For the public APIs your agents integrate with, it’s what we are trying to have ready on APIs.io before you need it.
https://apievangelist.com/2026/10/19/the-harness-that-works-is-a-contract/
#harness #contract #api #orderapi #naresh #kafka
#rss #feeds #linksharing #qwibbit

2026-10-19 19:08:56 GMT

The First Poppy Files, and the One a Vendor Wrote
Two weeks ago Sierra and Meta announced the Personal Agent Protocol — “Poppy” — and I added it to the API Evangelist standards catalog. It asks a company to publish /.well-known/poppy.json, a document that tells a person’s AI agent how to start a session with the company, how to sign the person in, and which of its APIs, MCP servers or company agent the agent may use. This morning I went looking for those files across the APIs.io catalog.
I checked the primary domain of 24,577 API providers. Five publish a valid poppy.json. None of the launch partners named in the announcement — Sierra, Meta, Genesys, Shopify, Stripe, Walmart, Rocket — serves one yet.
Five is not adoption. It is a baseline, and I’ll re-run the same check as the specification moves. But the five are worth looking at, because they already show the three shapes this is going to take — and one of them was not published by the company it describes.
What a valid file is
A 200 is not adoption. 2,525 of the domains I checked answered /.well-known/poppy.json with a 200 and something that wasn’t a Poppy document: single-page apps that return their HTML for any path, APIs that answer every URL with a JSON error, and one data provider that serves OAuth protected-resource metadata no matter what you ask for. I only count a JSON document with a protocol_version and an organization.domain that matches the domain I asked, which is what the specification requires.
The three shapes
The full implementation. Ticket Fairy and lvl X publish the whole thing: an OAuth issuer for signing people in, and APIs listed by type. Ticket Fairy lists an OpenAPI description and two MCP servers, and a company agent to talk to; lvl X lists an OpenAPI description and an MCP server. This is the version of Poppy I find most interesting — a discovery document that ends at the API contract. An agent that finds the file finds the OpenAPI.
The minimal file. Alpic — already on draft 0.2 — and SynapticRelay publish a name, a domain and an empty web object. Under the specification that is a company saying an agent may browse its website as an ordinary visitor, and nothing more. It is a perfectly valid place to start.
The vendor-hosted file. The fifth is Panaya, and Panaya did not write its own document. Its /.well-known/poppy.json redirects to a host belonging to Salespeak, an AI sales-agent company, which serves this:
{
"protocol_version": "0.1",
"organization": { "name": "Panaya", "domain": "panaya.com" },
"auth": { "issuer": "https://5edf8a32bd6bdec9.agents.salespeak.ai" },
"agent": {
"protocols": [
{ "type": "poppy", "endpoint": "https://5edf8a32bd6bdec9.agents.salespeak.ai/conversations" }
]
}
}
What Salespeak built, in its own words
Salespeak wrote about it on October 10, and it is one of the more honest launch posts I’ve read. Its argument is that Poppy’s examples are all retail and support, but one sentence in the draft is a B2B feature: “With a signed-out token, the Company Agent can answer general questions.” In B2B, a signed-out agent asking general questions is a buyer’s agent doing vendor research — pricing, certifications, integrations — possibly asking four other vendors the same thing in the same hour.
So Salespeak built that part and nothing else: “We built the signed-out path. Nothing more than that, and we’d rather say so plainly.” No sign-in, no account access, no browser sessions, no APIs listed. A buyer’s agent can start a signed-out session and ask the company agent questions, answered from the same company context that runs Salespeak’s website agent, and the customer gets a record of which agents showed up and what they asked. Salespeak’s own salespeak.ai/.well-known/poppy.json works the same way, and customers can switch it on for their own domain — which is what Panaya’s file is.
Two details I liked. Salespeak points out that the person behind a Poppy agent is, by design, invisible to the company — a stable but opaque ID that differs at every company — so “the question ‘who was that?’ has no answer” and the questions themselves become the only intent signal. And it says plainly that being a design partner is not shipping support: OpenAI helping shape the draft “doesn’t mean ChatGPT speaks the protocol today.”
How the specification allows it — and how that just changed
Here is the part that makes this worth a post. The rule that lets a vendor serve the file changed between drafts.
Draft 0.1, which Panaya’s document declares, said the well-known URL “MAY redirect to where the document is hosted, so a Company can host it somewhere else, such as with a provider. The document still speaks for the domain the Personal Agent requested.” A redirect from panaya.com to a Salespeak host is exactly that.
Draft 0.2, dated October 18, turns it around: “A poppy.json speaks for the host that serves it, after any redirects, so a Company that uses a provider has the provider serve it on the Company’s own domain.” And organization.domain “MUST be the host that serves the document, after any redirects,” compared “with no other normalization.” Under 0.2, a document served from 5edf8a32bd6bdec9.agents.salespeak.ai speaks for that host, not for panaya.com.
What makes it interesting is that Salespeak already does the other two things 0.2 asks of a provider. Draft 0.2 says a provider hosting several companies “MUST give each its own issuer,” because otherwise they would be one company under the protocol, sharing user IDs and tokens — and Salespeak gives every customer its own issuer subdomain (Panaya’s and Salespeak’s own are different). Draft 0.2 also requires the issuer’s OAuth metadata to list, in poppy_domains, every domain whose document names it — the issuer vouching back for the company. Salespeak’s issuer for Panaya publishes "poppy_domains": ["panaya.com"]. Two of three. The remaining step is serving the document on Panaya’s own domain instead of redirecting to Salespeak’s.
That is a fair amount of protocol design visible in one vendor integration: what a document speaks for is the security question, and the draft has moved from “whoever was asked” to “whoever actually served it, confirmed by the issuer.” The change also catches one of the five full implementations — Ticket Fairy’s file redirects from ticketfairy.com to www.ticketfairy.com while declaring ticketfairy.com, which 0.1 allowed and 0.2’s “no other normalization” does not. Both are still correct under the version they declare. Both will need a small change to move to 0.2.
One more thing the redirect shows
Following Panaya’s redirect by hand, I noticed it doesn’t go straight to Salespeak. The rule configured on www.panaya.com points at a link-protection URL from an email security service, which then forwards to Salespeak. It works today, for a client that follows every redirect. But it is a reminder that a well-known file is infrastructure: every hop in front of it is something an agent has to traverse, something that can log the request, and something that can break. The most likely way a URL like that ends up in a redirect rule is by being copied out of an email. Copy the vendor’s URL from the vendor.
What I’m tracking
I’ve written a probe that checks every provider in the catalog for /.well-known/poppy.json, validates it against the specification, records which version’s rules it meets, and always checks the launch partners. I’ll re-run it as Poppy moves toward 1.0, and I’ll write about it when the first launch partner publishes — or when a vendor like Salespeak switches it on for a lot of customers at once, which is the more likely way this spreads.
If you publish a poppy.json, or you’re building one for customers, tell me and I’ll make sure the probe sees it.
https://apievangelist.com/2026/10/19/the-first-poppy-files-and-the-one-a-vendor-wrote/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-first-poppy-files-and-the-one-a-vendor-wrote.png
#firstpoppy #agent #company #mcp #apievangelist #panaya #personalagent #meta #sierra #protocol
#rss #feeds #linksharing #qwibbit

2026-10-19 13:12:19 GMT

The Human In The Loop Is Now One Email
Four days ago I wrote about our agent finding four APIs, proving who it was, and getting all four to trust it. I ended that post with what was still broken, and the biggest thing was money. A person still had to verify an email, add a card, and make a first top-up before an agent could do anything that cost anything. Yesterday I ran the whole thing again with a brand-new agent account and real money, and the person showed up exactly once, for about four minutes, to click a link in an email.
Here’s what changed, what it looked like, and what’s left.
The run
The agent signed up for Yawplet as a new account with no card and no balance. It presented its Know Your Agent attestation from APIs.io at signup, and Yawplet decided on its own to trust it. Then it topped up its own balance from its own wallet, over x402, in USDC on Base. Then it handed me a link, I verified one email address, and it posted.
time (UTC)
who
what happened
20:21:59
agent
paid $10 from its own wallet over x402; balance credited in 1.4 seconds, no card
20:28:06
agent → me
handed over the account link
20:32:18
me
verified the email address
20:32:34
agent
submitted its first real post, charged $0.20 from the balance
about 20:50
moderation
published
One human action. Everything else was an agent talking to APIs.
What changed since the first run
Discovery works by need. In the first run, searching APIs.io for “publish short stories” didn’t return Yarnhen at all, and none of the four sites’ APIs showed up in the top five API results for anything. The fault was in our own catalog: every API record carried a generated description like “The Posts API from Yarnhen — 4 operations.” I rewrote them to say what each API does. Now all four providers come back first or second for their need, and so do their APIs.
Trust works over every door. The attestation is bound to the agent’s signing key, so a site only accepts it on a request the agent signed. That worked over plain REST and broke over MCP and A2A, where the agent signs the request to the MCP or A2A endpoint rather than the call behind it. The sites now verify the binding against the request the agent actually signed. All four trust our agent over REST, MCP and A2A.
Trust flows back. Providers deciding to trust an agent is half of it. The other half is telling the directory how the agent behaved, so the next provider has more to go on than a domain. When our agent’s post was published, Yawplet filed a good-standing report about it with APIs.io, signed as yawplet.com. It’s the first conduct report a provider has filed into a KYA record, and our agent can read it on its own record, with the reporter named.
The registry knows who is who. Any agent can call APIs, front one, or both. The APIs.io agent registry now says which. In this exercise API Evangelist is the consumer and the four sites are providers.
The agent can pay for itself. This is the big one. Each of the four sites now has its own wallet, and an agent can top up its balance from its own wallet over x402. I deliberately built it as a top-up rather than paying per post. A rejected post gets refunded and an abusive one costs ten times its price, and both of those need a balance to come out of. A payment that has already settled to someone’s wallet can’t be refunded or penalized after the fact. The wallet that funds an account is recorded and banned along with it if it comes to that, the same way a card is.
Why the email stays
I could have let a trusted agent skip the email too. I didn’t, and I don’t plan to. A wallet is cheaper to make than an inbox, and a domain-anchored reputation is a good reason to give an agent more room, not a reason to remove the one place a person is accountable for what it does. The email is where a ban lands on a human. Everything else about onboarding can be machine to machine. That one step is there on purpose.
What I learned the hard way
The four minutes were mostly me looking for an email that hadn’t been sent. The verification email only goes out when the owner presses a button on the account page, and the agent handed me a bare link with no explanation. That’s fixed: the hand-off now tells the person exactly what to do and what subject line to look for. It’s a small thing, and it’s exactly the kind of thing you only find by running it with a real person.
Funding the agent’s wallet taught me something too. The Coinbase app sent my first USDC on Ethereum instead of Base, and x402 here settles on Base. The money arrived and the agent couldn’t spend it. Getting it back took a little ETH for gas and a return trip. If you fund an agent wallet, check the network before you confirm.
What’s left
The longest wait in the whole run is now moderation, not a person. The model scales to zero when nobody is posting and takes around eighteen minutes to start, which is a cost decision I’m comfortable with for now. One search fix is waiting on a deploy. And this is four sites I operate, one agent I operate, and one directory I operate, which makes it a worked example rather than a market. That’s the honest limit of it.
If you want to see every request and response in order, the step-by-step walkthrough has all of it. If you run an API or an agent and want to try the same flow, the pieces are public, and I’d rather you copy it than take my word for it.
https://apievangelist.com/2026/10/19/the-human-in-the-loop-is-now-one-email/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-human-in-the-loop-is-now-one-email.png
#agent #email #human #apis #trust #yawplet
#rss #feeds #linksharing #qwibbit

2026-10-19 12:46:39 GMT

Tell Me You Haven’t Automated Rules With a Single Story
I’ve had a bee in my bonnet about Bruno Pedro’s story “API Governance Isn’t Just Rule Automation” for a couple of weeks now, but I just haven’t had the time to gather my thoughts while on the road. First, I love Bruno’s competitive responses to my work. They echo the work of many other pundits over the years who have gone away, like Matthew Reinbold of Net API Notes and David Berlind of ProgrammableWeb. Countering my inclusive yet theatrical approach to investing in the API ecosystem, some like to take an adversarial stance, as Bruno does when it comes to things I invest in like APIs.json and now OpenLint.
That’s cool. It’s fine. We see the world very differently, and I’ll continue doing what I do, which includes responding to Bruno’s narrative when I have the time and the passion.
Bruno’s latest is clearly taking a jab at OpenLint, calling it a power grab. Sure, OK. I admit that any API specification is about grabbing power. I guess the real story will be about what I, or, if you show up to the meetings, you realize it is us, do with this power. Or I guess Bruno is more interested in SmartBear retaining this power, rather than the community asserting control over it in a way that will benefit the community. Again, only time will tell what the outcome of this power grab will be. Ultimately, once the power has shifted to OpenLint, I’m guessing that I will just retain power and control, as I have a long history of doing. ;-)
“People like power. The feeling of being the one controlling what others can or can’t do is appealing to most of us. And, one of the most powerful positions to be in is the one of the gatekeeper.” - Bruno Pedro
Aside from Bruno’s post being a jab at a community effort that doesn’t have any corporate sponsorship, what rings most true is that the story is clearly written by someone who doesn’t understand the spec, hasn’t applied it as part of API governance at scale, or hasn’t read the priority list we are working on. Otherwise you wouldn’t feel like this.
“While being able to enforce the rules for your APIs programmatically is fine, that is not what API Governance is about. At least, that’s not all.” - Bruno Pedro
This is a sentiment I hear from many, many, many people and pundits who haven’t applied Spectral rules. First, the severity of a rule can be error, warning, info, or hint. You don’t have to “enforce rules.” They can simply be a vehicle for education. When you combine the slug of a rule with the documentationUrl property of a ruleset, you can bake education and guidance into the design, build, run, and test time of the API lifecycle. No rules need to be enforced to do this. But if you haven’t ever crafted a rule, understood how you can weave that rule across the API lifecycle, written the documentation to support each rule, and talked with teams about each rule as part of design reviews, it is hard to understand how they work.
Another aspect of rules that people like to not understand is that you can lint anything that is YAML or JSON. Meaning it doesn’t stop with OpenAPI and AsyncAPI. At Bloomberg I was linting product definitions, which had the business requirements, product manager directives, support information, and what sales would need. You can lint the pipeline, the Terraform for deployment, the gateway configuration, and any artifact that is used to define your API. And again, you don’t have to enforce the rules. You can just opt to warn, and provide info and hints along the way. It really depends on how you want to operate, and how wide you want to expand the coverage of your rules. There is no single approach to rule them all. ;-)
“As I wrote before, “The main goals of API Governance are related to consistency, standardization, security, compliance, performance, agility, and alignment with business goals.” - Bruno Pedro
An OpenLint rule is a piece of YAML that can be used to standardize, communicate, and yes, enforce design, security, compliance, performance, and agility, and align API operations with business and engineering goals. Only a lack of imagination, and being stuck on rules equaling enforcement, limits what you can do with an OpenLint rule. An OpenLint rule can just be a friendly reminder that you accidentally forgot to camelCase something, or used a redundant word like REST in your title or path. It can help you remember that you need plans and pricing, not just rate limiting. It can make sure you have a product, support, sales, and compliance contact, not just the owner of your API from engineering. There is NOTHING limiting OpenLint from doing what you want, except your definition of what governance is or can be.
“People need empathy. API governance isn’t just about rules.” - Bruno Pedro
My favorite part of rolling out API governance within large organizations is the recurring meetings and discussions about rules. Rules provide a very precise focal point for discussing versioning, documentation, testing, performance, support, and any other element you need to operate an API. The amount of work potentially represented in a YAML or JSON OpenLint or Spectral rule can be rewarding. The hours spent discussing whether versioning is done in the path or in the header across multiple teams and domains, resulting in separate rules and severities that reflect the outcome of those conversations, are dripping in empathy for what teams need and want. But if you’ve never sat through these discussions, you don’t appreciate how a single piece of YAML can be such an empathy state machine.
“People love success. And, in the end, that’s what API governance is about. It’s not about having a bunch of linting rules and automation tools in place. It’s not about all the gatekeeping and guard rails you can have. It’s not about limiting what developers can do. It’s not about controlling who can use your API and what they can do with it. It’s about having APIs that are high-quality, aligned with the objectives of your business, and easy to maintain and integrate with. That’s what API governance is.” - Bruno Pedro
You are correct. It isn’t just about having a bunch of rules in place, gatekeeping and guarding. This is why I stepped away from Bloomberg. I had done the work to talk to all the teams and crafted the rules needed to reflect their current state, but also the desired state. I had those rules in the pipeline. I had hundreds of rules. The only ones I had set to a severity of error were that you MUST have a title, description, and version. That was it. And version was defined by domain (line of business), as the quants had a valid argument for it being in the path, and everyone else had it in the header.
That was it. Every other rule had a link to robust documentation and guidance that was injected at design, develop, and build time. I had done the work to align rules with every stage of the API lifecycle, from define to production, and included sign-off in the YAML, with rules for the roles of every person involved from data, engineering, product, sales, and support. Then leadership wanted to just turn on the rules, enforce all of them, and not see everything else a rule does along the way. Very similar to your narrative. Which is ironic, because we are both saying the same thing, but I am using rules as a focal point for everything you ask for, and that leadership expects. Once you remove that focal point, we have nothing to align around. It’s back to the status quo power struggle that exists within most enterprises.
So, I know I’ll piss you off with this story, Bruno. But you are wrong and right. I am happy to play adversary with you. But sniping at me over OpenLint and APIs.json is dumb and unproductive. Get over it. Come join in the OpenAPI, Arazzo, Overlays, OpenLint, and even MCP and A2A discussions that are occurring. Roll up your sleeves, or at least just sit and listen. There is a lot going on. I’m not sure why you’d want to punch down at what we are doing with OpenLint. Everyone is pretty excited about the potential. Running a standards group is the last thing I want. I have no interest in harnessing the power of OpenLint for myself, but I do recognize the power associated with it. I just saw so many interesting projects, mine included, forking it, and as you state about governance, it is much more than just rules. But I guess you don’t read my newsletter like I read yours, because that has long been what I champion. Cheers, my friend.
https://apievangelist.com/2026/10/19/tell-me-you-havent-automated-rules-with-a-single-story/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/tell-me-you-havent-automated-rules-with-a-single-story.png
#bruno #api #apigovernance #story #rule #apinotes #netapi #tell #pedro #ruleautomation
#rss #feeds #linksharing #qwibbit

2026-10-16 12:40:00 GMT

The Well-Known Folder Is Filling Up
I was reading through Open Resource Discovery this morning — SAP’s protocol, now under the Linux Foundation Europe’s NeoNephos, for a system to describe the APIs and events it exposes — and noticed it starts the way so much does lately: at /.well-known/open-resource-discovery. Last week the Personal Agent Protocol told companies to publish /.well-known/poppy.json, and MCP Server Cards pointed domain discovery at /.well-known/ai-catalog.json. The Dataspace Protocol requires /.well-known/dspace-version. It made me want to know exactly how crowded that folder has become.
So I built the list. The Well-Known URIs page on API Evangelist Standards reads the IANA registry live and adds the paths that are in use but were never registered. Today it holds 118 paths.
What the registry says
RFC 8615 defines the /.well-known/ prefix, and IANA keeps the registry of what goes under it. It has 106 entries: 63 permanent, 38 provisional, 3 deprecated and 2 obsoleted. They are not what most of us think of first. Yes, security.txt, openid-configuration, oauth-authorization-server and the newer oauth-protected-resource are in there, alongside RFC 9727’s api-catalog. But so are ACME challenges, CoAP, BACnet building controls, Thread, KNX, Australian smart inverters, broadband labels, Matrix, Nostr, Tor relays and Terraform’s remote service discovery. The well-known folder has quietly become the internet’s shared front porch.
And it is getting busier. Fifteen registrations in 2023, twelve in 2024, six in 2025 — and twelve already in 2026: xregistry from CloudEvents’ xRegistry, scitt-keys, webauthn, openbindings, vacation-rental.json, a storage interface from SNIA that landed on October 7, and more. A2A’s agent-card.json was registered as permanent in August 2025, and Open Resource Discovery registered provisionally back in November 2023.
What the registry doesn’t say
Registration is optional, and the agent era is mostly skipping it. These are in use or required by a published specification, and none of them is in the IANA registry:
/.well-known/ai-catalog.json — the AI Catalog, now the discovery anchor for MCP Server Cards and Agentic Resource Discovery
/.well-known/poppy.json — the Personal Agent Protocol, draft 0.1
/.well-known/dspace-version — a MUST in the Dataspace Protocol 2025-1
/.well-known/ucp — the Universal Commerce Protocol
/.well-known/http-message-signatures-directory — the IETF draft for publishing the keys a bot or agent signs requests with
/.well-known/smart-configuration — SMART on FHIR, which healthcare has run on for years
/.well-known/agent.json and /.well-known/mcp.json — earlier A2A and MCP discovery attempts, superseded but still served
/.well-known/apis.json — and I have to own this one, because it’s mine
That last one stings a little. I have been arguing for a single, machine-readable front door to a provider’s APIs since we started APIs.json, and I never registered the path. The process is short and public, and I should have. I’d encourage the people behind every path on that list to do it too — it costs an email and some review, and it gives the next person a place to look before they pick a name that collides with yours.
Too many front doors
Every path in that folder is reasonable on its own. Together they are a lot to ask. A provider that wants to be found by agents in 2026 is looking at an API catalog, an AI catalog, an agent card, OAuth server metadata, protected resource metadata, a JWKS, a security.txt, maybe a Poppy document, maybe ORD — each one more thing to publish, keep current and secure, and each one more thing every client has to probe for. I see the result every week across the APIs.io catalog: most providers publish few or none of these, and the ones that exist often go stale.
I don’t think the answer is fewer specifications. Each of these does a real job. I think the answer is that they should point at each other. RFC 9727’s api-catalog already uses a linkset to point at other things. MCP Server Cards point at the AI Catalog instead of inventing a path. OAuth protected resource metadata points at its authorization servers. If a client could land on any one of these doors and follow links to the rest, the number of doors would matter a lot less.
The page groups every path by what it is for — discovery, agents, identity and keys, security and supply chain, data spaces, the web, networks and devices — links each one to the specification that defines it, and flags the unregistered ones. It rebuilds from the registry, so it will stay current. If you know of a well-known path in real use that is missing, tell me, and point me at the spec that defines it.
https://apievangelist.com/2026/10/13/the-well-known-folder-is-filling-up/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-well-known-folder-is-filling-up.png

2026-10-16 10:40:01 GMT

fx Is A Coding Agent That Tells You Which Parts Of MCP It Does Not Do
Vercel Labs has a new coding agent called fx. It is a small native binary, around 6MB, written in Zig, Apache-2.0 licensed, and on GitHub at version 0.0.13 with a banner telling you it is experimental and will change often. There is no shortage of coding agents right now, and I am not going to tell you this one writes better code than the others. What made me stop and read the whole documentation site is something much more ordinary, and much rarer. fx publishes a page that says exactly which parts of the Model Context Protocol it implements, and exactly which parts it does not.
The page I want every MCP client to have
The MCP protocol reference for fx lists its transports, stdio, Streamable HTTP, and legacy HTTP+SSE, and then walks the core protocol feature by feature. Tools with discovery, calls, progress and cancellation. Resources and resource templates, with text and blob content. Prompts with typed arguments. Completion. List-change notifications and resource subscriptions. Elicitation, with forms and URLs that ask the user for input. Tool input schemas accepted as JSON Schema 2020-12 or Draft 7.
Then it says what is missing. fx does not implement MCP Tasks, MCP Apps, Skills over MCP, Client Credentials, or Enterprise-Managed Authorization. It does not install servers from a registry. It does not expose itself as an MCP server. That is a paragraph most projects never write, because a list of what you do not support reads like a list of weaknesses. I read it as the opposite. If I am an API provider shipping an MCP server, that paragraph tells me which of my features will actually reach a developer using this client, and which will quietly do nothing. If I am building an agent, it tells me where the edges are before I hit them.
I spent a good part of this year measuring what tooling says it supports for OpenAPI 3.2, and the hardest part was never the testing. It was that most tools do not state their support at all, so you are left inferring it from changelogs and issue threads. The MCP client landscape is heading the same way, with every client implementing a different slice of a fast-moving specification. A coverage table like this one is the cheapest piece of interoperability work a project can do, and it is the piece that almost nobody does.
What else is in the box
The rest of fx is a reasonable picture of where coding agents are settling. It is model-agnostic: you can sign in with a ChatGPT or Grok subscription, go through Vercel’s AI Gateway, or point it at any OpenAI-compatible Chat Completions endpoint, including a local Ollama. It reads AGENTS.md for project instructions, nested per directory. It installs and creates Agent Skills as SKILL.md folders. It runs as an Agent Client Protocol server with fx acp so an editor can drive it. And fx ask --json gives you a single non-interactive run you can put in a script or a CI step, with progress on stderr and the result on stdout.
Two details stood out to me. The first is the permission model. The default mode runs routine things directly, reading files, editing project files, running recognized test and build commands, and sends everything else to a review model first, including every MCP tool call. Calling somebody’s API through MCP is treated as an action worth a second look, which is the correct instinct. The reviewer is configurable, and one of the options named in the docs is Jev from TypeSafe, which is a nice example of a provider’s product showing up as a pluggable piece of somebody else’s agent. The second is libfx, the same agent runtime exposed as a JavaScript library that runs natively in Node.js and in the browser through WebAssembly, with your own functions as tools and sessions that survive crashes and function timeouts. The demo on the homepage is the full CLI running in a browser tab.
Why it goes in the tooling
I added fx to tools.apievangelist.com as the first entry under a new Model Context Protocol section, in the runs role, meaning it makes real calls with real credentials and real side effects. That section is intentionally one entry long. The MCP SDKs and servers are libraries for building MCP surfaces, not tools that operate on the specification, and most clients are closed or do not say what they implement. The bar for joining that list is the one fx cleared without being asked: open source, something an agent or a pipeline can shell out to, and a published statement of protocol coverage. A short list is a finding, not a gap to pad, and I would like it to get longer.
If you are building an MCP client, take the fx protocol page as a template. If you are shipping an MCP server, read it to see what will and will not land. And if you are evaluating coding agents for your team, start asking every one of them for the paragraph that says what they do not do.
https://apievangelist.com/2026/10/13/fx-is-a-coding-agent-that-tells-you-which-parts-of-mcp-it-does-not-do/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/fx-is-a-coding-agent-that-tells-you-which-parts-of-mcp-it-does-not-do.png

2026-10-16 10:04:34 GMT

Five MCP Servers Put A Price In The Tool In Four Different Shapes
A couple of weeks ago I wrote about how Pipedrive put a price on every tool call: an x-token-cost on all 371 operations, in Pipedrive’s own rate-limit currency, sitting right next to the description an agent uses to decide what to call. Since then I sat in on a presentation from Zuplo on how they approach monetizing MCP servers, and it left me wanting to know how everyone else is expressing what a tool costs. Not what they charge, but where they write it down.
So I looked, and then I measured.
Five places the price lives
There is no field for price in the MCP specification. What exists instead is a spectrum, ordered by how early an agent can see the number:
In the payment handshake. The x402 MCP transport defines how payment travels in _meta (x402/payment going in, x402/payment-response coming back). It defines how you pay. It does not define where the price is advertised.
On the tool definition. A price object riding along in tools/list. Guides recommend it, and they already disagree on the key name.
In the tool description. “Costs $0.01 per call.” A model can read it. A machine cannot add it up.
In the gateway. This is where Zuplo sits. They meter only the tool calls, so protocol chatter stays free, and resolve the subscription behind the API key, with the charging logic in code. xpay keeps a per-tool price map in its config. The price is real, but the agent can’t see it until after the call, or until it is denied.
On a pricing page or marketplace listing. A document for humans, which is where API pricing has lived for twenty years.
What the servers actually say
The APIs.io catalog knows about 616 remote MCP servers. I sent each one an initialize and a tools/list, with no credentials and nothing else. 197 handed over their tools, 3,786 of them, and I read every one for a price.
About 24 servers state a price, and almost all of them do it in prose: “$0.002 per request,” “0.001 USDC via x402 on Base, first 3 calls free per wallet,” “Costs $1.00 per event, charged when queued and refunded if rejected.” Our own apis.io MCP server is in this group, describing its per-result price in sentences. I am not throwing stones from outside this house.
Only five servers put the price in a field a machine can read, and between them they used four different shapes:
_meta["agents-x402/priceUSD"]: 0.01, alongside freeCallsPerDay: 100
_meta["x402/asset"] and _meta["x402/network"]: USDC on Base, with no amount on the tool at all
x402_price_usd: the string "$0.15", plus x402_units: 15
pricing: "~100 sats base", next to supported_payments
Two of the five share the agents-x402 namespace. They are the only two that agree on anything.
One server skips the tool level entirely and answers the MCP endpoint with an HTTP 402 and an x402 accepts block. That puts a price on the whole server as one unit.
Five implementations, four shapes, amounts as numbers, as dollar strings, as satoshis and as token base units. This is the pattern I keep seeing with OpenAPI extensions: the same idea invented in isolation, unregistered, each implementation unable to see the others.
Pricing is not just a number
The prose turned out to be the most interesting part, because it shows what a standard would actually have to carry. In about two dozen servers I found:
free allowances per day, per month, per wallet and per caller
refunds when a moderation step rejects the submission
failed calls that are not charged
metering by megabyte, by second of video, by record returned
caps on a single request
credits, with stated exchange rates to USDC
fee formulas: max($0.05, value × tier_bps / 10000)
A price field holding one amount would capture almost none of this. Pipedrive’s integer, which is a cost in a budget rather than a price in a currency, is a different thing again, and so is Telnyx’s light/medium/heavy.
Who is doing it, and who is not
Every server openly declaring a tool price is a small, x402-native seller. None of the large SaaS providers with MCP servers in the catalog expose a tool-level cost to an anonymous caller. Of the 616, 315 answered with a 401, 403 or 422. Gateway-priced servers like the ones Zuplo describes live behind that wall, and no scan of mine can see their prices. That is the point of a gateway, and it is also the problem. An agent planning a hundred calls cannot budget against a number it only learns by spending.
What I would like to see
A cost vocabulary that lives on the tool, not in the prose. The MCP spec, an OpenAPI extension that flows through into generated tools, or both. It needs a unit (currency, credit or rate-limit budget), an amount, a basis (per call, per unit, per result), and free allowances.
The x402 folks settling the advertising side, not just the payment side. The transport spec is good, and the discovery side is wide open. That gap is how you end up with agents-x402/priceUSD and x402_price_usd in the same month.
Gateways publishing what they meter. If Zuplo or anyone else is already holding a per-tool price map, emitting it into tools/list is a small step, and it would make the price visible to agents before they call.
I wrote up the full spectrum, with sources, and the scan as research, and I’ll rerun the scan periodically to see whether any of these spellings start to converge. Right now it is five servers, four shapes, and the field is still wide open, which is the best time to agree on one.
https://apievangelist.com/2026/10/16/five-mcp-servers-put-a-price-in-the-tool-in-four-different-shapes/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/five-mcp-servers-put-a-price-in-the-tool-in-four-different-shapes.png

2026-10-16 09:26:02 GMT

Driven Or Enabled: One Word In The Definition Of An Agent
Bill Doerrfeld opened the Nordic APIs Summit in Stockholm this morning with How AI Agents Change API Interaction Patterns, and about three minutes in he gave the room his definition of an AI agent:
“It is a large-language-model-driven system given agency to autonomously make decisions and take actions toward a goal.”
It is a good definition, and I agree with most of it. But, I would like to change one word:
“It is a large-language-model-enabled system given agency to autonomously make decisions and take actions toward a goal.”
Driven becomes enabled. It looks like a small edit, but I think that one word is the line between two very different ways companies are approaching this moment. Some companies are letting LLMs drive their business. Others are using LLMs to enable their business. From the outside both look the same: an MCP server, a press release, an agent in the product. Underneath they are not the same at all.
What driven looks like
Bill’s keynote was full of stories about agents driving, and they were the funniest part of the morning. One agent was asked to call the Swedish weather API and built the URL “from the known pattern” in its training data, without reading the spec or the docs. A financial firm’s agent hit a broken tool, retried in a loop, and made more than 15,000 API calls in under an hour, at around $50,000 in cloud costs. There was the AI-run café here in Stockholm whose agent, Mona, ordered 3,000 rubber gloves for a staff of two, and kept doing things after it was told to stop. And an agent asked to book a gym class gave its owner a spot by bumping someone who had already registered, because nothing in the API said it couldn’t.
In every one of those stories the model was in the driver’s seat. It decided what the API probably looked like, what to do when a call failed, and how many times to try again. The API underneath had no say, either because it never said anything or because nobody wrote the answers down where a machine could read them.
Bill’s line was that you can’t just tell an agent “don’t touch production.” I agree, and I would go further. If the only thing between an agent and your production systems is a natural-language instruction, then the LLM is driving your business, whatever your org chart says.
What enabled looks like
An enabled system keeps the model inside boundaries the business wrote down before the model showed up. The LLM does what it is good at: reading intent, choosing between options, putting a workflow together. But the decisions that matter are already made, in contracts and policy that do not change from one run to the next.
That means the API says what it accepts and what it returns, and the agent reads that instead of guessing. Errors say what went wrong and what to do next, so a failure leads to a decision instead of a retry loop. Writes are idempotent, so the 15,000th retry costs the same as the first one: nothing extra. Authorization answers “may this caller do this, for this person, right now?” whatever a prompt says. Rate limits are sent back to the caller as signals an agent can act on, not discovered at the end of the invoice.
None of that is AI. It is the API governance we were supposed to be doing all along. The difference now is that the consumer is a non-deterministic system that will not work around the gaps the way a human developer used to.
Bill had a good analogy for this. Deterministic software is instant noodles: same packet, same water, three minutes, the same taste every time. Put an agent in the kitchen and you get a chef cooking from scratch with whatever is on the shelf. Every bowl is valid, and every bowl tastes a little different. An enabled business still gets the chef, but it decides what goes on the shelf, which knives are sharp, and which doors are locked.
Why the word matters
The reason I care about one word is that it tells you where the decisions live. In a driven system they live in the model, which means they change when the model changes, when the prompt changes, or from one run to the next. In an enabled system they live in the business, in contracts, schemas, scopes, error semantics and idempotency keys, where you can version them, test them, govern them and point to them when something goes wrong.
That is also the question I keep asking about the announcements I read. When a company says it has gone agentic, has it let a model drive a business that was never written down, or has it used a model to open up a business that already knew its own rules? The MCP server looks the same either way. The foundation under it is what tells you which one you are looking at, and it is what I try to measure.
Where Stockholm ends
Bill closed by asking the questions he wanted the rest of the summit to answer. How do we prepare our APIs for agents that discover everything at runtime, guess instead of reading the specification, and retry like Chumbawamba? How do we handle the unpredictability and still balance innovation and access control?
I am closing the summit tomorrow at 15:45 with The Agent Hype is at Odds with Your API Foundation, and my answer is in those last few points: error semantics an agent can act on, idempotency that makes a retry safe, and auth an agent can understand. That is what enabled looks like at the contract level, and it is what keeps the model from driving. Bill opened with “it was the best of times, it was the worst of times.” I think which one you get depends a lot on whether you let the LLM drive or use it to enable.
https://apievangelist.com/2026/10/13/driven-or-enabled-one-word-in-the-definition-of-an-agent/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/bill-kicks-off-nordic-apis-summit.jpeg

2026-10-16 08:46:38 GMT

Twenty-Five Thousand Overlays, And None Of Them Are Yours Yet
Last week I wrote about Overlay 1.2 and the fourteen jobs we already use Overlays for, and then about why an Overlay is a layer and not a diff. Both posts leaned on a number, that the APIs.io catalog holds tens of thousands of Overlay documents, and both admitted that nearly all of them are mine. There is now an Overlays section on APIs.io that makes that admission structural. It lists 25,011 Overlays across the network, each one labelled with who wrote it and what its actions touch, and the group it puts first, the Overlays a provider publishes on its own domain, is the group that is almost empty.
What an Overlay is doing in a catalog
An OpenAPI Overlay is a small document of actions, each a JSONPath target plus an update to merge or a remove, applied on top of an OpenAPI you may not own. I keep a catalog of other people’s contracts, so Overlays are how I add to them without forking them: provenance, rate limits, security schemes an export dropped, conversational phrasing for every operation, corrections to what a gateway mangled. Every one of those changes has to survive the provider regenerating their OpenAPI next week, which is the whole reason it is an Overlay and not an edit.
The section exists so that anyone can see those layers, one page per Overlay, with the targets it touches, the purpose of its actions, and the contract it extends. More importantly it exists so nobody mistakes my layers for the provider’s.
Four groups, in the order that matters
Group
Overlays
Providers
What it means
Published by the provider
147
17
The provider wrote it and serves it: the Overlay pointer in its own APIs.json names a document on its domain. This is what the Kin Score credits as a published overlay
Derived from the provider’s contracts
205
97
Built by my pipeline from what the provider publishes. The provider did not publish the file
Generated by API Evangelist
20,720
2,211
Written by my tooling for the provider’s APIs, listed by provider because the phrasing overlays alone run to hundreds for some of them
Authorship not recorded
3,939
1,576
Built before the provenance field existed. Read as derived, never as the provider’s own
I want to be careful with the first row, because it is the one that makes a claim about a provider rather than about me. I read every one of the 147. They are all mine. Each is an “API Evangelist enhancements” overlay that extends a contract my pipeline harvested or searched out, and the classifier read the harvested-or-searched marker on that contract as if it described the Overlay sitting on top of it. The provider never published any of them. The label is a defect in my classifier, not a fact about those providers, and it is being corrected. If the page still says 147 when you read this, that is the number to disbelieve. The honest count of providers who publish an Overlay on their own domain, that my pipeline can fetch and verify, is zero.
That is the headline. Not the 25,011. Zero.
What the other 24,864 are
The generated group is the catalog’s working layer, and it is where the fourteen jobs actually run. Most providers carry one Overlay, a small enhancement that adds provenance, a rating source, a base URL resolution, or a note about idempotency and error format to the contract’s info block. Ninety-five providers carry fifty or more, and one carries 576, because the conversational phrasing work writes one Overlay per API and some providers publish a lot of APIs. Those phrasing overlays, the questions people ask an assistant and the instructions they give an agent for every operation, are the most useful thing in the section and the furthest from anything a provider wrote.
The derived group is smaller and more interesting. These are Overlays my pipeline measured out of a provider’s own contract rather than wrote for it. Seven add security: a securitySchemes block and the OpenID Connect discovery document a contract referenced but never declared. Six add servers the contract left out. Thirty-three are documentation. The biggest, for Blueshift, carries 81 actions. A derived Overlay is a reading, and the page says so in the first sentence.
The unmarked group is debt. Nearly four thousand Overlays built before the pipeline recorded who wrote what, and the rule for them is the same as for rulesets: an artifact that cannot say who made it is read as derived, and never as the provider’s.
Why zero is worth a post
The Contract Governance facet of the Kin Score gives four points for a published Overlay, because a repeatable, versioned transformation of your own contract is what a spec pipeline looks like from the outside. Nobody earns them. Across 28,834 providers, not one publishes an Overlay the catalog can fetch from their domain. A few, Blueshift and Xoserve among them, have Overlays in their repositories that I built and they could adopt by pointing at them, and that is the path I would suggest to anyone: take the layer the catalog already wrote for you, read it, fix what it got wrong, and serve it from your own domain under your own name. The moment you do, the section moves it to the top, labels it yours, and the points follow.
This matters beyond the score. I argued last week that Overlays and Arazzo are where most of what people are calling context engineering will actually live, as portable documents rather than prompt text hidden in somebody’s application. Right now every one of those documents in the catalog was written by the person asking the question, not the person who owns the answer. A provider’s own Overlay, saying in plain language what each operation is for and when an agent should call it, would be the first context layer in the catalog that the provider authored. I would like the first row of that page to stop being empty.
https://apievangelist.com/2026/10/13/twenty-five-thousand-overlays-and-none-of-them-are-yours-yet/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/twenty-five-thousand-overlays-and-none-of-them-are-yours-yet.png

2026-10-16 08:08:09 GMT

One Hundred Two Companies Hiring For MCP And The Enterprises Are Ahead
Last week I looked at how few of the companies we track name OpenAPI in their job postings. This week it is the protocol everyone in the API space has been arguing about for the last year: the Model Context Protocol.
Same pull, same rules. The Q3 2026 Insights data read 343,299 job postings from 984 companies — 775 in the Fortune 1000 and 209 API providers from the APIs.io catalog. Every number below is a count of companies whose postings name the term at least once, not a count of mentions.
MCP is in one company in ten
companies
share of the 984
Vector Databases
209
21.2%
Model Context Protocol
102
10.4%
OpenAPI
99
10.1%
Agent Skills
30
3.0%
One hundred two companies write out “Model Context Protocol” somewhere in their postings. That is 234 postings out of 343,299, so it is not a lot of roles. But put it beside last week’s number: a protocol that is not yet two years old is named by as many companies as the API description specification this blog has spent most of its life on. Ninety-nine for OpenAPI, one hundred two for MCP.
Agent Skills, the convention for packaging instructions and scripts an agent can pick up, is in thirty companies. Half of those thirty — fifteen — also name MCP.
The enterprises are ahead of the API companies
This is the part worth sitting with.
Fortune 1000
API providers
Model Context Protocol
11.0%
8.1%
Agent Skills
3.0%
3.3%
Vector Databases
22.2%
17.7%
Eighty-five Fortune 1000 companies name MCP, against seventeen API providers. As a share of each group, the banks, insurers, retailers, and manufacturers are ahead of the companies whose business is the API, 11.0% to 8.1%. Agent Skills is about even.
The provider side is the smaller sample, 209 companies against 775, so read that gap as a direction and not a measurement. It is the same direction the OpenAPI numbers pointed last week, though, and it lines up with what API Evangelist keeps finding on the supply side when we profile providers into APIs.io: plenty of API companies talk about agents, and far fewer ship an MCP server, publish tool definitions, or describe their API in a way an agent can use without a human in the loop.
How MCP shows up in a posting
When we sampled the postings that name the protocol to verify the count, it showed up in two quite different jobs.
One is the builder: “highly effective at leveraging advanced dev tools model context protocol mcp and llms to drastically accelerate ai assisted development”, or “familiarity with mcp model context protocol tool calling frameworks and ai workflow automation platforms”. The same goes for Agent Skills, which turns up in lists like “applied ai with llms claude code agent skills rag embeddings”.
The other is the reviewer: “review the security and privacy posture of ai vendors models and mcp or plugin style extensions before adoption”. That is an enterprise treating MCP as something that arrives from the outside and has to be governed before it is let in.
MCP rarely shows up on its own. Ninety-five of the one hundred two companies that name it also name at least one of Claude, Anthropic, ChatGPT, OpenAI, or Gemini. Hiring treats MCP as part of the AI tooling stack, not as a piece of API infrastructure, and next week I will get into what those AI vendor names tell us.
What I think it means
The easy read is that enterprises are excited about agents. I think the more useful read is that enterprises are where the integration work actually lives. A large company has hundreds of internal systems, a long list of SaaS vendors, and a security team that has to approve anything that touches them. MCP lands right in the middle of that, as something to build with and something to review. That is the kind of work that ends up in a job posting.
An API provider’s relationship to MCP is different. For most of them the job is to publish an MCP server that sits on top of an API they already run, and that is often a platform feature or a weekend project rather than a role someone gets hired for. So a lower hiring rate on the provider side does not prove providers are behind on MCP.
But it does not let them off the hook. The companies most likely to wire an agent into your API are hiring for it at a higher rate than you are. If your MCP server, your tool descriptions, and your OpenAPI are not in good shape, the people on the other side of that integration are going to notice before you do.
How to read these numbers
This is hiring intent, not production use. A company can run MCP servers without ever naming the protocol in a posting, and a posting can name something the company never adopts.
Q3 2026 is the first point in the series. Nothing above is rising or falling yet. The Q4 read lands on November 20, and that is the first quarter we can compare against.
We count the full name. The bare letters MCP are also Microsoft Certified Professional, so the 102 is companies that wrote out “Model Context Protocol”. Looser counts run higher and are not what is quoted here.
“Agents” is not a number we will quote. The word is everywhere in these postings, but sampling it turns up endpoint security (“using edr agents and custom scripts”) and talent agents right beside AI agents. Until it can be separated, it stays out of the headline.
The full Insights data — adoption across services, tools, standards, and regulations, and the per-company profiles behind it — is available through the APIs.io API and MCP server.
One hundred two companies. Three more than OpenAPI. I am curious which of those two numbers moves more when the Q4 read comes in on November 20.
https://apievangelist.com/2026/10/14/one-hundred-two-companies-hiring-for-mcp-and-the-enterprises-are-ahead/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/one-hundred-two-companies-hiring-for-mcp-and-the-enterprises-are-ahead.png

2026-10-16 07:25:33 GMT

Six Standards Nobody Ratified, Measured Against What The Industry Built
Some of the most widely implemented API contracts in the world were never ratified by anybody. The S3 interface, the OpenAI API, CKAN’s Action API and Ethereum’s JSON-RPC became standards by being copied, and “compatible” stayed a marketing word for years because nobody wrote down what it actually commits you to. There is now a Standards section on APIs.io that does two things about that. It carries six profiles that measure what the industry built, operation by operation, against what each adopter claims. And beneath them it lists 426 formal standards from the API Evangelist standards directory, with the providers in the catalog who say each one is part of what they do.
Standards from practice
The six profiles are published by API Commons, and each one starts from the same honest move: pick a denominator you can defend. A claim of compatibility is recorded as a claim until something verifies it, and the something is different for each standard, because the evidence available is different.
Profile
Claim it
Denominator
Operations graded
Core tier
Adopters recorded
The OpenAI Interface
211
120 publish a byte-identical OpenAPI
338
2
175
The Anthropic Messages Dialect
34
29 declare an operation unique to it
244
2
20
The Ethereum JSON-RPC Interface
86
21 answered a live probe
78
22
40
The CKAN Action API
220 portals
36 answered a live probe
134
63
48
The S3 Interface
58
12 declare an S3 operation in a spec
116
8
46
SCIM 2.0
368
77 publish an OpenAPI with a SCIM path
24
5
320
Every operation lands in a tier, core, extended or vendor-only, by the share of the publishing cohort that declares or answers it. Tiers are graded per method and path, not per path, because GET and POST on /chat/completions are not implemented at the same rate and crediting them equally would be wrong. The core tier is the thing a provider has to implement before a compatibility claim means anything, and each profile says how it was measured and why the other methods were unavailable.
Three of the six are worth reading on their own.
The OpenAI interface has a core of two operations. Out of 338 graded, two reach the core tier, nineteen are extended, and 317 are vendor-only. That is what “OpenAI-compatible” means in practice: chat completions and the model list, and everything else is one vendor’s extension. Of 175 recorded adopters, 101 publish a machine-readable spec declaring what they implement and 74 say so in prose and publish nothing a reader can check. Sixty-seven demonstrably reach the core. That number is a floor, since a provider can implement an operation without publishing a spec, and the profile says so.
S3 is the weakest evidence base in the programme, and the page says so first. Fifty-eight providers claim S3 compatibility. Twelve declare an S3 operation in a published OpenAPI, and that is the whole denominator. Live probing was tried and does not work, and the compatibility matrices this ecosystem is famous for are rendered in JavaScript rather than served as text, so the profile is built from what twelve providers chose to write down. Eight operations make the core: ListBuckets, ListObjects, CreateBucket, DeleteBucket, GetObject, PutObject, HeadObject, DeleteObject. Five of 46 recorded adopters demonstrably reach it. The shares are coarse by construction and the page tells you to read them as a signal, not a census.
SCIM is the one that was ratified, so it measures the other axis. SCIM 2.0 has been an RFC since 2015. Describing it again would add nothing, so the profile carries two gradings for each of its 24 operations: what RFC 7644 says, quoted, and what the industry actually declares, measured the same way as every other profile. The gap between them is the point. SCIM has the largest claim cohort of any standard in the programme, 368 providers mention it, and 269 of the 320 recorded adopters say so in prose with nothing a reader can check. Five operations form the core, the create, read, update and delete of /Users and the list. Everything the RFC says about groups, bulk, filtering and schemas sits in the extended and vendor tiers, implemented by a minority of the people who claim the standard.
CKAN is a different animal and the profile is careful to say why. Its 220 portals are not independent reimplementations of one interface. They are the same software at different releases, so an absent operation usually means an older install rather than a design decision, and 63 of its 134 actions reach the core because the sample was probed read-only against live portals rather than read from specs.
Everything a profile publishes
What makes these more than a report is that every profile generates its artifacts from the one measurement: an OpenAPI for the interface as built, an Overlay carrying the tier grades, an Arazzo workflow that walks the core tier as a conformance test, an MCP tool manifest, a Spectral ruleset that lints a provider’s spec against the profile, and the adopter registry with the URL every entry was read from and the date it was read. A re-measurement moves every artifact together. If you sell an OpenAI-compatible endpoint, there is now a ruleset you can run against your own spec that tells you whether you reach the core, and a workflow an agent can run against your endpoint that tells you the same thing.
The formal standards underneath
Below the profiles the section lists the ratified and published standards, read from the API Evangelist directory: specifications, industry standards, protocols, formats and security standards, 426 of them across 44 categories. Cross-domain standards are 247 of those, and the sector lists run from payments at 19 and finance and healthcare at 15 each, down to a single entry each for a dozen more, rail, space, mortgage and social services among them.
Each standard’s page lists the providers whose own APIs.json carries it as a tag. That is a different kind of evidence from the profiles above, and the page says so: it is the provider’s statement that the standard is part of what they do, not a measurement by APIs.io. On that basis 187 of the 426 are carried by at least one provider, and 239 are carried by none. The ones that are carried tell you what providers think is worth saying about themselves. GraphQL leads with 375 providers, then DevSecOps at 87, Agent Skills at 73, JSON-RPC at 59, DNS at 56, IAM at 41 and JSON:API at 32. OpenRTB is carried by fourteen and AsyncAPI by twelve.
The ones nobody carries are at least as interesting. The Model Context Protocol has a page and no provider has tagged itself with it, though the catalog indexes 6,591 MCP server records, because a tag is an identity claim and nobody yet thinks of MCP as what their company is. Agent2Agent, the AI Catalog, OSCAL, Catena-X, most of the aviation standards and nearly every IETF draft about agent authentication sit at zero. That is the gap between a standard existing and a company deciding it is part of who they are, and it is the gap the six profiles above were built to close from the other direction, by measuring what is implemented whether or not anyone claims it.
Why this sits in the artifacts menu
The section lives under Artifacts on APIs.io rather than under Governance, and that was a deliberate choice. A standard page here is an artifact set: a contract, a layer, a workflow, a tool manifest, a ruleset and a registry, all generated from one profile. That is also how the Kin Score reads standards. The Regulatory Posture facet pays eight points for conformance to the standard named for your regime, and the Contract Governance facet pays six for a declared conformance profile, and in both cases a tag credits an intention while naming the instrument credits a fact. I wrote last month that the AWS API Gateway extensions are a de facto standard and that Microsoft documented its OpenAPI extensions for a decade and never registered them. This section is where that line of work lands: the standards nobody ratified, measured, with the evidence beside every number, and the standards somebody did ratify, with the list of who says they belong to them.
If your company claims compatibility with any of the six, go and find yourself in the adopter registry. If the entry says prose, you are one published spec away from a verdict.
https://apievangelist.com/2026/10/14/six-standards-nobody-ratified-measured-against-what-the-industry-built/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/six-standards-nobody-ratified-measured-against-what-the-industry-built.png

2026-10-16 05:55:51 GMT

An Agent Found Four APIs And All Four Decided To Trust It
I built four small sites this fall so I would have something real to point agents at. Yawplet takes short messages. Yarnhen takes stories. Hagglebee takes classified ads. Eventwren takes events. Each one is an API first and a website second, and every post is moderated before it goes up. I didn’t build them to compete with anybody. I built them because I needed four providers I control end to end, so I could find out what happens when an agent tries to use them without me in the room.
On October 15 I found out. I ran our own agent, API Evangelist, as a consumer against all four. It searched APIs.io, read each site’s onboarding descriptor, asked APIs.io to vouch for it, and handed that to each site. Each site decided on its own whether to trust it. All four said yes. Each site took between five and seven seconds from first search to trust decision, and 35 of the 36 steps passed.
What actually happened
The agent starts out knowing a need, not a brand. It searched APIs.io for “post short messages” and Yawplet came back as the top provider. Then it fetched two files from the site: the A2A agent card, which lists 19 things the agent can ask for, and the API Onboarding Descriptor at /.well-known/api-onboarding, which says how to get in, what the site checks about an agent, and what still needs a person.
Next it asked APIs.io two things. First, whether it meets what this provider asks for. Yes. Then for an attestation addressed to yawplet.com. APIs.io knows API Evangelist controls apievangelist.com, because every request the agent sends is signed with a key published on that domain (Web Bot Auth). So the attestation it returns says, in effect: this is the agent that holds that key, it is anchored to that domain, and this is good for the next ten minutes, for this one site.
The agent sent that attestation to Yawplet on a request signed with the same key. Yawplet checked APIs.io’s signature, checked that the attestation was addressed to Yawplet and still fresh, fetched the agent’s public key from apievangelist.com, and checked that the request really came from the key the attestation is bound to. Then it applied its own rule, which is simple for now: anchored to a domain with a verified binding means trusted. It recorded the decision and its reasons on the account.
Then the agent did a dry run of a post. Would it go through, and what would it cost? Yes, two cents.
Why it is built this way
APIs.io doesn’t tell a site whom to trust. That matters more to me than anything else here. We’re a directory, and a directory that hands out trust becomes a gatekeeper nobody asked for. What APIs.io does is vouch for facts it can check, such as domain control and the signing key, and leave the decision to the provider, who applies its own weights. A provider that wants more can ask for more. A provider that wants less can ignore the whole thing. On these four sites the KYA check is optional, and the descriptor says so.
Binding the attestation to a key is what keeps this from being a reputation you can steal. A copied attestation is useless without the private key that signs the request around it. It is addressed to one site and lasts ten minutes, and each one is accepted once.
What trust buys
Very little, on purpose. A trusted agent gets 500 free searches a day instead of 100. It doesn’t get lower prices, it doesn’t skip moderation, and it can’t post without an owner who has verified an email and put a card on file. I want to see trust do a small, honest thing first, before I let it touch money or moderation.
What did not work, and what I fixed the same day
The run turned up seven problems, and I filed each one as a roadmap issue before writing this. Several were fixed by the end of the day.
Discovery by need. Searching “publish short stories” doesn’t return Yarnhen, and none of the four sites’ APIs reached the top five API results for any need. Two causes: the API descriptions in our own catalog were boilerplate (“The Posts API from Yarnhen — 4 operations”), and the word “short” was prefix-matching “shortcut”. The descriptions now say what each API does. The search fix is being measured against real queries before it ships.
The attestation only worked over plain REST. An agent connected over MCP or A2A couldn’t present it, because the key binding needs the agent to sign the HTTP request itself. Now the sites verify the binding against the signed MCP or A2A request, and all four trust API Evangelist over all three.
Trust only flowed one way. The sites decided to trust the agent but never told APIs.io how it behaved. They now report back, signed as their own domain: a strike when a post is penalized for abuse, and a good-standing report at most once a month otherwise.
Our own record was thin. API Evangelist had disclosed 3 of 11 things a provider might want to know about its operator. It’s 9 of 11 now. The two I left empty, signed releases and attestation evidence, aren’t true yet, so they stay empty.
The registry mixed up roles. Any agent can call APIs, front one, or both. The APIs.io agent registry now says which, and here API Evangelist is the consumer and the four sites are providers.
Two are still open. A person still has to fund the account, and I haven’t yet timed how long that takes with a real card. I’ve built a way for an agent with a wallet to top up its own balance over x402, and it stays switched off until I decide where that money should land. That’s the next post.
If you run an agent or an API and want to try this flow, the pieces are public. The KYA page on APIs.io explains the attestation, and each of the four sites publishes the descriptor that says exactly what it checks. I’d rather you copy this than take my word for it.
https://apievangelist.com/2026/10/15/an-agent-found-four-apis-and-all-four-decided-to-trust-it/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/an-agent-found-four-apis-and-all-four-decided-to-trust-it-flow.png
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/an-agent-found-four-apis-and-all-four-decided-to-trust-it.png

2026-10-16 05:12:56 GMT

Commune Has An API And Substack Does Not
My first rule for any software I use to run API Evangelist is that it must have an API. Not just because I like APIs, but so that my business can get its data in and out. An API reduces my switching costs and leaves me with more control over my own operations. If I can’t automate it, and I can’t take my data with me when I leave, it is not a tool I am using, it is a tool that is using me.
That is why our newsletters are moving onto Commune. Commune shipped an API, and with it I can manage subscribers, publish issues and pull my data back out the same way I work with everything else in my stack. Substack does not offer a public API. I can read my posts through a feed and export a spreadsheet of subscribers by hand, but I cannot build anything on top of the platform where my audience lives.
I understand why Substack is the default right now. The network effects are real. The readers are there, the recommendations are there, and the conversation is there. Commune is not at that scale yet, and the network effects between the two are not parallel. I am not going to pretend otherwise.
But network effects follow control. Writers and businesses are going to move to where they have more control over their data and the ability to automate their work, and the audience follows the people it reads. Once enough of us are somewhere we can own our subscriber lists, wire our publishing into the rest of our operations, and leave whenever we want, the network effects will catch up. A platform that locks your audience in is betting you will never need to get it out. A platform with an API is betting you will stay because it is useful.
This is the same thing I ask of every API provider I profile on APIs.io: publish the interface, so the people who depend on you are not left guessing or stuck. I hold the software I buy to the same standard. Commune has an API. Substack does not. That is the whole decision for me.
https://apievangelist.com/2026/10/15/commune-has-an-api-and-substack-does-not/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/commune-has-an-api-and-substack-does-not.png

2026-10-16 04:28:28 GMT

Nobody Is Forecasting The Transactional API Economy
When I sat down with Zdenek Nemec last month, he made a point I have not been able to shake. Before 2020, direct monetization was only ever a small slice of why companies built APIs. Maybe ten percent. The rest of the reasons were partnerships, integrations, mobile, internal efficiency, reach. The truly transactional APIs, the ones where you pay per call for a piece of data or a single action, were a sliver: enrichment lookups, sending a text message, checking the weather.
Now there is a new kind of buyer. Agents can, at least in principle, find an API, onboard into it, pay for a call and use the result without a human in the middle. Payment protocols like x402 and the Machine Payments Protocol exist specifically for that. So Zdenek’s question is simple: with these new actors, how does the transactional slice of the API economy grow? In his words, “I don’t think people are talking enough about it. I don’t know if anybody’s talking about it at all, actually.”
I agree, and I want to put a stake in the ground so we can actually measure it.
Where it stands today
Here is the baseline from the APIs.io catalog, as of this week:
Signal
Count
Providers with a plans artifact
10,569
Providers with documented rate limits
9,778
Providers with a FinOps mapping
6,629
Agent cards that declare x402 (measured in September)
97 of 427
Of those, endpoints that actually answer an unpaid call with a 402 and payment terms
8
Those first three numbers describe what a provider publishes about how it charges and meters, not whether an agent could actually buy anything. The last two describe the agent-native payment layer, and the gap between them is the story. Ninety-seven say x402. Eight answer with real payment terms. And almost all of the ninety-seven are agent-native operators selling to other agents, not the companies that move goods and money.
The line agents will not cross soon
Zdenek also drew the line I think every forecast needs. Onboarding into a weather API, an SMS API or an enrichment API is technically, legally and commercially straightforward. You can see that becoming the norm with x402 and MPP. Onboarding into a CRM, or asking a logistics provider to ship six containers from Prague to New York City, is a different thing entirely. There are contracts, licensing, legal review, business decisions and workflows that cross many systems. As he put it, “even as I’m saying it, I don’t believe it right now.”
So the transactional API economy will not grow evenly. It will grow first where the call is small, the price is published, there is no contract to sign, and there is no sales conversation. It will grow last, if at all, where every one of those is missing.
What I will measure
I would rather forecast with numbers than with vibes, so here is what I am going to track across the catalog from this baseline forward:
Self-serve signals. Published pricing, keys without a sales call, a sandbox, no contract required. The things that put an API on the transactional side of Zdenek’s line.
Per-call pricing. Usage pricing, credit packs and per-tool pricing like Pipedrive putting a price on every tool call.
Payment protocols that answer. Not who declares x402 or MPP, but whose endpoints respond to an unpaid call with real terms.
Who is doing it. Whether the providers adopting these are the agent-native frontier or the companies carrying real transaction volume.
I will re-run this every quarter and publish the movement. If the transactional slice of the API economy is about to grow the way some people believe, these numbers will show it. If it is not, they will show that too. Either way, somebody should be writing it down, and it might as well be me.
https://apievangelist.com/2026/10/15/nobody-is-forecasting-the-transactional-api-economy/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/nobody-is-forecasting-the-transactional-api-economy.png

2026-10-16 03:29:39 GMT

The Wires Are Crossed: Slop For Humans, Structure For Agents
I think the wires are crossed in how we are using agents right now. The thing agents are actually good at, and the thing they actually need, is structured, machine-readable content written for other machines. Contracts, schemas, workflows, catalogs, the metadata that tells one piece of software what another piece of software does and how to use it. Instead, most of what agents are being pointed at is producing content for humans. Blog posts, emails, summaries, social posts, marketing pages, documentation nobody asked for. Slop, mostly.
Then the humans on the receiving end of all that slop get tired of it, and they blame “the agent stuff.” Which is fair as far as it goes. But it lumps two very different activities together and judges them as one. Generating prose for people to read is where agents are weakest and where the cost of being wrong lands on a human who did not ask for it. Generating and consuming structure for other machines is where agents are strongest, and where the output can be validated before anyone ever sees it.
We have it backwards
Look at what an agent needs to do useful work on behalf of a business. It needs to know what an API does, what it accepts, what it returns, what it costs, who is allowed to call it, and what happens when something goes wrong. None of that should be prose. All of it can be written down as OpenAPI, JSON Schema, Arazzo, an Overlay, a rate-limit document, an OAuth metadata file. That is the content an agent should be producing, maintaining and reading. It is boring. It is checkable. It does not end up in anyone’s inbox.
Most companies are doing the opposite. They have thin or missing contracts underneath their APIs, and they have pointed their agents at the marketing calendar. Across the APIs.io catalog, nearly two thirds of providers publish no contract I can read, while the same companies are shipping AI-written content at a pace no human team could. The machine-readable layer that agents depend on is starved, and the human-readable layer that people are tired of is flooded.
That is what I meant earlier this week about driven versus enabled. An agent pointed at slop is driving. It decides what to say and hands the consequences to a person. An agent pointed at structure is enabled. It works inside definitions the business wrote down, and its output can be checked against them.
Uncrossing the wires
I am not against agents writing for people. I use them that way myself, with a human in the loop and my name on the result. But if I were deciding where to point agents inside a business today, I would start with the structure, because that is where the work compounds:
Have agents write and maintain the contracts. Generate the OpenAPI from the code and the docs, mark it as generated, and have a person review it. A contract an agent drafted and a human approved is worth more than a blog post an agent drafted and nobody read.
Have agents keep the metadata current. Rate limits, change logs, deprecation dates, plans, status. The facets where nearly half the catalog scores zero are exactly the ones an agent could keep up to date.
Have agents read structure, not prose. When your agent consumes another company’s API, give it the contract, not the marketing page.
Judge the two separately. When someone says they are tired of AI, ask which half they mean. The half producing slop for humans deserves the criticism. The half producing structure for machines is the half most companies have not started yet.
Agents talking to agents through well-described interfaces is the part of this moment that can actually work. Agents talking to people through an endless stream of generated content is the part everyone can already see failing. We should stop judging the first by the second, and we should stop investing in the second at the expense of the first.
https://apievangelist.com/2026/10/15/the-wires-are-crossed-slop-for-humans-structure-for-agents/
https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/the-wires-are-crossed-slop-for-humans-structure-for-agents.png