---
title: Publishing Plans, Rate Limits, and FinOps for 3,837 API Providers
url: http://apievangelist.com/blog/2026/05/04/publishing-plans-rate-limits-and-finops-for-3837-api-providers/
date: '2026-05-04'
author: ''
feed_url: https://apievangelist.com/atom.xml
---
I just finished work to publish three new machine-readable artifacts — API Commons Plans & Pricing, API Commons Rate Limits, and a FinOps Foundation FOCUS-aligned framework across as many API providers in the API Evangelist Network that I can. That ended up being 3,837 of the 5,127 repositories in the API Evangelist GitHub network. 11,511 new YAML artifacts. What I consider to be a full Tier 1 set of 184 well-known API providers possessing the devil in the details when it comes to the business of these APIs. The Gap I Was Trying to Close For many years I have been making the case that an OpenAPI and AsyncAPI are the leading machine-readable artifacts API providers should be publishing. OpenAPI for synchronous APIs. AsyncAPI for event-driven APIs. JSON Schema for data shapes and validation. JSON-LD for vocabulary. Spectral rulesets for governance. And APIs.json to tie them all together at a known URL. What I have not been making the case for strongly enough recently, and something AI agents have made urgent, is the financial half of the API contract. The OpenAPI spec tells a consumer how to call the API. It does not tell the consumer what the call costs, what tier they are on, what their throughput allowance is, what the meter rolls up to on the invoice, or what the dimensions are that let them allocate cost back to a team, domain, or line of business. None of that lives in any of the existing machine-readable specs. For a developer building a one-off integration, the gap is fine. They read the pricing page, sign up, watch their first invoice, and learn. The discovery loop is human-paced. For an AI agent making decisions at machine speed across hundreds of providers, the gap is load-bearing. The agent can fetch the OpenAPI spec and call the right endpoint with the right parameters and get the right response — and have no idea whether that call cost a hundredth of a cent or fifty dollars. It cannot pick the cheaper of two equivalent providers. It cannot stop itself before exhausting a quota. It cannot tell its caller what the bill is going to look like over time. The fix is the same thing I have been arguing for a while now: publish the missing data as a machine-readable file, in the provider’s repo, indexed by APIs.json, alongside everything else. Three new artifact types — plans, rate limits, finops. This will help close the busienss gap I am speaking of. What Got Generated This work happened in two phases. Phase one Generated scaffold artifacts for every qualifying API provider in the API Evangelist network. A provider qualifies if its apis.yml declares at least one API in the apis: array — which matched 3,837 of the 5,127 repos. For each qualifying provider I generated three YAML files in three new directories: plans/{provider}-plans-pricing.yml — three scaffold tiers (Free, Professional, Enterprise) with placeholder limits and prices, conforming to the API Commons Plans schema. rate-limits/{provider}-rate-limits.yml — standard...