Nostr notes by Kin Lane (Unofficial)

Scale, Stop And Start Your Kubernetes Clusters Automatically With ...

2026-10-30T21:15:11Z

Scale, Stop And Start Your Kubernetes Clusters Automatically With Azure Kubernetes Service

If your business runs its applications on Azure, there is a good chance a monthly bill has made you ask an uncomfortable question: why are we paying for all those servers overnight, when nobody is using them? The next questions are usually how to add capacity before a busy season, and how to stop depending on one engineer’s memory to do it. Azure Kubernetes Service can take those jobs on through an API, a way for software to talk directly to other software, so a scheduled script, your internal tools or an AI assistant can resize, stop and start your infrastructure on request.
What Azure Kubernetes Service does
Kubernetes is the widely used system for running applications across a group of servers, called a cluster, and it restarts and rearranges those applications as needed. It is powerful, and it is a lot of work to look after. Azure Kubernetes Service, usually shortened to AKS, is Microsoft’s hosted version. Azure takes on the operational overhead, including critical tasks like health monitoring and maintenance, and your team focuses on what runs on top. More on the Microsoft website.
Two terms are worth knowing before going further. A node is one of the servers in a cluster, and a node pool, which Azure’s API calls an agent pool, is a group of identical nodes. Most of what affects your bill comes down to how many nodes you have in which pools, and that is what this API lets you control.
What you can get done
Run your infrastructure from software instead of by hand
IT Infrastructure Management is the one capability here, and APIs.io maps 24 operations to it. They divide into two practical jobs.
The first is knowing what you have. Before anyone can make a decision about cost or risk, they need an accurate list of clusters, and in larger organizations those lists tend to go stale. These calls let you build an inventory that is always current:
GET /subscriptions/{subscriptionId}/providers/Microsoft.ContainerService/managedClusters lists every AKS cluster across your Azure subscription, your account’s billing boundary.
GET /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters narrows that list to one resource group, a folder for related Azure resources.
GET /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/agentPools lists the node pools in one cluster.
The second is changing capacity and keeping it current. Adding room for a sales event, removing a pool nobody uses, and checking for upgrades before they become urgent are all things you can schedule rather than remember:
PUT /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/agentPools/{agentPoolName} adds a node pool, or changes the size and settings of an existing one.
DELETE /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/agentPools/{agentPoolName} removes a node pool you no longer use.
GET /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/agentPools/{agentPoolName}/upgradeProfiles/default tells you whether an upgrade is available for a node pool.
Workflows that put it together
A workflow is a recipe of several calls in order that finishes a real job. Many AKS jobs take minutes, so most of these recipes include polling, which simply means checking back until the work is done. APIs.io catalogs 10 for AKS, including:
Stop Cluster stops a running cluster and waits until it has finished. Pointed at a test environment in the evening, this is the job that answers the overnight question.
Start Cluster starts a stopped cluster and fetches the credentials needed to use it.
Scale Node Pool reads a pool, changes its node count and waits for the change to finish.
Add Node Pool and Poll adds a new pool and waits until it is ready.
Provision Cluster and Fetch Credentials creates a cluster, waits for it and retrieves the admin credentials.
Rotate Cluster Certificates renews the security certificates on a cluster and refreshes user credentials.
Ask for it in plain language
Our conversational overlay for AKS 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 see every AKS cluster across my whole Azure subscription?”
“What node pools does my AKS cluster have?”
“How do I add a new node pool to an existing AKS cluster?”
“Can I scale or change the settings of a node pool that already exists?”
“Is there an upgrade available for one of my AKS node pools?”
You can see one in the Managed Clusters phrasing overlay.
Getting started
You can sign up for AKS yourself, and Microsoft publishes the pricing details. For how access works, read the identity concepts and how to control access to cluster credentials. If timing matters to you, see planned maintenance, which covers when updates can be deployed. On APIs.io, see the AKS profile, the Managed Clusters API, the Agent Pools API and the Maintenance Configurations API. Ask your team which non-production cluster could safely stop tonight, and start there.

https://apievangelist.com/2026/10/30/scale-stop-and-start-your-kubernetes-clusters-automatically-with-azure-kubernetes-service/

#kubernetesservice #azurekubernetes #subscriptionid #get #resourcegroups #api #infrastructure #microsoft #aks

#rss #feeds #linksharing #qwibbit

Google Ships Agent Skills Like Products, And That’s The ...

2026-10-29T22:03:27Z

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/

#likeproducts #agentskills #googleagent #api #every #need #styleguide #scripts

#rss #feeds #linksharing #qwibbit

Run Code Without Managing Servers And Release It Safely With AWS ...

2026-10-29T21:23:38Z

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/

#awslambda #function #code #release #version #awsregion #run #get #httpsfunction #order

#rss #feeds #linksharing #qwibbit

Who Actually Gets To Define API Standards Every API standard ...

2026-10-28T19:38:52Z

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/

#apistandards #gets #spectral #everyapi

#rss #feeds #linksharing #qwibbit

Run Your Catalog, Pricing, And Customers In Software With ...

2026-10-27T18:40:05Z

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/

#post #customers #tax #get #management #catalog #bigcommerce #marketing #api #price

#rss #feeds #linksharing #qwibbit

Regulation Writes The API Outside of tech, Australia’s API ...

2026-10-27T14:59:05Z

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/

#cds #consumerdata #api #cdsapis #origincds #westpaccds #apisnab #krakenapis #australia #energyaustraliacds

#rss #feeds #linksharing #qwibbit

The Most Programmable Sectors In Australia Australia is ...

2026-10-27T05:33:23Z

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/

#australia #own #api #sector #energy #companies #tech #government #data #mcp

#rss #feeds #linksharing #qwibbit

Start With The Flow, Not The Agent A lot of companies are asking ...

2026-10-27T04:57:52Z

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/

#mcp #agents #api #flow #own

#rss #feeds #linksharing #qwibbit

Automate Projects, Tasks And Team Goals With Asana Every growing ...

2026-10-27T01:36:20Z

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/

#asana #projects #goals #team #api #get #portfolios #tasks #work #post

#rss #feeds #linksharing #qwibbit

Take Payments, Run Subscriptions And Send Invoices With Stripe ...

2026-10-27T01:03:10Z

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/

#rss #feeds #linksharing #qwibbit

Create, Track And Report On Issues Automatically With Jira If ...

2026-10-27T00:29:09Z

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/

#jira #issuesautomatically #security #management #incident #get #post #jiraalign #jiraservice #create

#rss #feeds #linksharing #qwibbit

Insurance: The Shape Of The Answer Is Behind A Login Earlier this ...

2026-10-23T13:36:24Z

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/

#shape #acord #answer #insurance #standards #xml #acordtranscriber #json #turn #annuityxml

#rss #feeds #linksharing #qwibbit

A Banker Said Finance Does Not Have Enough MCP Servers And They ...

2026-10-22T20:56:29Z

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/

#mcp #mcpservers #bank #newyork #financial #onlinemcp

#rss #feeds #linksharing #qwibbit

Payments And Banking: The Shape Of The Answer Earlier this week I ...

2026-10-22T20:22:39Z

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/

#openbanking #shape #answer #consumerdata #datastandards #fdx #berlingroup #iso #json #turn

#rss #feeds #linksharing #qwibbit

Where The Market Layer Of The Kin Score Stands Nine days ago I ...

2026-10-21T16:12:06Z

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/

#kinscore #marketlayer #open #standards #integration #pci #every #pcisecurity

#rss #feeds #linksharing #qwibbit

Healthcare: The Shape Of The Answer Yesterday I wrote about ...

2026-10-21T14:56:07Z

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/

#shape #fhir #answer #healthcare #claim #bulkdata #dataaccess #priorauthorization #bundle #core

#rss #feeds #linksharing #qwibbit

The Incumbent And The Challenger: NCR Voyix And Lightspeed I hear ...

2026-10-20T19:47:42Z

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/

#ncrvoyix #lightspeed #challenger #incumbent #agent #restaurant #kinscore #market #developer #access

#rss #feeds #linksharing #qwibbit

Every Regulated Market Already Publishes Its Own Map A week ago I ...

2026-10-19T20:23:43Z

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/

#marketalready #regulatedmarket #every #alreadypublishes #map #kinscore #domain #sec #api #formadv

#rss #feeds #linksharing #qwibbit

The Well-Known Folder Is Filling Up I was reading through Open ...

2026-10-16T12:40:00Z

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/

Driven Or Enabled: One Word In The Definition Of An Agent Bill ...

2026-10-16T09:26:02Z

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/

One Hundred Two Companies Hiring For MCP And The Enterprises Are ...

2026-10-16T08:08:09Z

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/