Which operations actually behave like their contract
An OpenAPI document is a claim about an API. Some are written by the provider, and some are generated from documentation. Either can be wrong or incomplete. The only way to know whether an operation behaves the way its contract says is to call it and compare. APIs.io does that one operation at a time, and records the result on every API page.
The statuses
| Status | What it means |
|---|---|
| declared | The operation is in a contract. Nobody has yet seen it answer. This is the default, and it isn’t shown. |
| observed | apis.io called it and got a successful JSON response, but the contract has no schema detailed enough to check that response against, or the response didn’t match it. |
| conformant | apis.io called it within the last 90 days, got a successful JSON response, and that response matched a schema with named fields. |
A status fades: an operation nobody has re-checked in 90 days stops being conformant. Conformant operations are the ones Stack offers for SDK and MCP generation. A generated client is only as good as the contract under it, and these are the operations we have seen honor theirs.
What we check today
The first wave ran on 2026-11-10:
- It used GET requests only, with no credentials, from an identifying User-Agent, at one request a second per provider.
- It covered 631 providers: every one in the catalog that answered at least one call without a key.
- 22,678 operations were in their contracts, and 3,241 across 412 providers are conformant. 2,914 more answered but couldn’t be checked.
- We store the status code, the content type, whether the response matched, and the names of any fields the contract doesn’t declare. We never store response values.
The same run checks auth. In 768 operations the contract says the operation is open, but it asked for a key. In 164 the contract says a key is required, but the operation answered without one. Both are contract fixes, and we will raise them with the providers.
What this does not claim
- It is not a security audit or an uptime guarantee. It means one call, on one date, matched the contract.
- It does not cover operations that need a key or change data. Most of the catalog is keyed, so most operations are still declared. That reflects how far the checking has reached, not the quality of those APIs.
- It covers the response, not every parameter. An operation called without its optional parameters is conformant on what was exercised.
How it grows: providers, developers, and us
Each operation’s status is built from evidence, and we want evidence from more than our own probes:
- Providers: run your test suite through a recording proxy and submit the result. Your sandbox and keyed operations then reach statuses we can’t reach on our own. If you have claimed your listing, you can already ask for a check through
request_checkon the APIs.io MCP server. - Developers: HAR files, proxy captures and Postman or Bruno run results from real integrations, redacted on your machine before anything is sent. Contributions are credited on the operations they help confirm. apis.io credits for accepted evidence will follow.
- Us: the probes re-run on a schedule, and keyed sandbox checks come next, GET first.
Submission tooling for providers and developers is being built. Until it ships, the fastest way to move an operation from declared to conformant is an example value for each required parameter in your contract (3,736 operations went unchecked for lack of one), and a response schema with named fields.