Ambiguous tags split into their distinct sensesdata

A tag that means several different things now carries them separately, each with the anchor tags that pin it and an honest count of the members not placed in any of them. `healthcare` splits into digital health, drug discovery, revenue cycle and clinical development; `payments` into checkout, open banking, crypto and cross-border. 91 tags carry senses, up from one. Where a member has no strong signal it stays unplaced and is counted as such, rather than being pushed into whichever sense fits least badly.

Clearer account copy, a narrower GitHub scope, and a data exportsite

The sign-in card said no email was required while signing in did share one. It now says what actually happens, and links the privacy policy and terms from the point of collection. Alongside that: the GitHub sign-in asks for the email scope only, having previously requested profile access we never stored; `GET /v1/auth/me/export` returns everything held against your account, with API keys masked; and `PATCH /v1/auth/me` lets you set your marketing preference, which defaults to off. Deleting an account now anonymises usage records rather than keeping them linked.

APIs.io publishes an A2A agent cardsite

`https://apis.io/.well-known/agent-card.json` describes what an agent can do here — search and read the catalog free, the paid synthesis surfaces, and the free correction path — with the OAuth flows an agent uses to register itself without a human. It describes the interfaces we actually serve, MCP and REST, and says so: APIs.io runs no native A2A JSON-RPC endpoint, and the card states that rather than advertising one.

A tag reports one member count, and it is the one you getapi

Every tag exposed its member count twice — on the tag itself and via the listing it links to — and the two disagreed on all forty of the largest tags, in both directions. Both now report the population the linked call actually returns, and the "N providers here" affordance quotes that same number. Some counts went down. The previous number included records the listing never returned.

Telling us the catalog is wrong about you no longer requires a paid plan or an MCP clientapi

`POST /v1/providers/{slug}/correction` is free, needs no key, and files into the same review queue everything else goes through — you get an id back and can poll it. Send what is wrong, what it should say, and a URL that shows it. It was previously reachable only over MCP, which meant a provider on plain HTTP could reach the paid check queue and not the free correction beside it. Correcting our own error is not a paid feature.

Looking up a company by its domain returns the domain's ownerapi

Resolving an apex domain could return a tenant on a subdomain of it rather than the company that owns the domain — a well-formed answer with a plausible reason attached, and no way to tell it was wrong. Resolution now weighs an exact domain match above a link from somewhere underneath it, and breaks ties on catalog quality rather than on ordering. Asking about a specific subdomain still returns whoever serves that subdomain, which was always the right answer for that question.

Remediation names the gate holding a provider back, not the biggest numberapi

Asking what to fix first used to return the largest available point gain. Where a provider has already earned the points for the next band and is held there by an unmet requirement, it now names that requirement instead — because points cannot clear a gate, however many you add. Affects every provider in that position: 642 of them at the time of the change.

Ratings now score whether a write API is safe to call twicedata

Kin Score 0.20.0 adds create-or-update ergonomics: whether a provider's write surface lets you create-or-update in one call, keyed on an identifier you already hold, and whether the response tells you which branch ran. Without it, every write needs a search-and-branch in front of it, and the first time that check is skipped a duplicate record is created. It applies only to providers that accept writes. A read-only API cannot upsert and is excluded rather than scored zero, and providers with no machine-readable contract are excluded too — the rating says which, on the provider's own page.

Stack recommendations pick the better provider among equal claimantsapi

Where several providers make the same categorical claim for a capability, the recommendation is now decided by catalog quality rather than by how closely a provider's name resembles the search term. A monitoring slot that resolved to a developing-band provider over four exemplar specialists now returns the specialist.

An unauthenticated call now answers 401 with a way in, not 402api

Calling a paid endpoint with no credential returns 401 and a challenge naming the resource metadata document, so a client can discover the authorization server, register itself and get a token without a human. Presenting a credential that is simply below the plan still returns 402, which is the different answer it always should have been: one means go authenticate, the other means go buy a plan. Clients treating 402 as "not authenticated" will see 401 for that case now.

2026-07-26Site

Stack — build a watchlist, export it as apis.yml

New top-level Stack page. Type-ahead your way through the catalog, add the providers you actually depend on, and watch them in one table: Kin Score and band, week-over-week movement, how far each has moved since you added it, agent readiness, API count, published resources, and access model — plus a rollup with the stack average and its weakest link.

Export the whole stack as an APIs.json 0.21 apis.yml (or JSON, or straight to the clipboard). Every provider carries its rating and agent-readiness blocks, its published resources — OpenAPI, MCP server, agent skills, rules, scopes, security, changelog — and an include pointer to the provider's own apis.yml. Upload one back to restore a stack on another machine; a single provider's own apis.yml works as an import too.

There is no account and nothing is sent to APIs.io: the stack lives in one first-party cookie in your browser, holding only provider slugs. Clear your cookies and it's gone — which is why the apis.yml download is the durable copy. About and Add API moved from the top nav down to the footer to make room.

2026-06-30Search

First-party (brand-owner) ranking signal

Quality rating was standing in for ownership; now search knows who owns a brand. A provider is the canonical owner of its own name plus any sub-brands it operates (e.g. Meta owns WhatsApp, Instagram, Messenger; Microsoft owns GitHub). When your search names a brand, that owner's first-party API gets an explicit bonus over third-party integrators — so "whatsapp" leads with the official WhatsApp APIs, not the dozens of tools that merely connect to WhatsApp. Non-brand queries (payments, weather) are unaffected.

2026-06-30Search

Quality- and ownership-aware search ranking

Search results were ordered by text relevance alone, so a query like "send WhatsApp message" buried the first-party WhatsApp Business API under a pile of lower-quality third-party matches. Ranking now blends relevance with the provider quality rating:

• Field boosting — a match in an API's name or tags now outweighs a passing mention in its description, so the API actually named after what you searched rises to the top.
• Quality-weighted ordering — among the APIs that match, the composite quality rating (Exemplar → Minimal) decides the order, so higher-quality, first-party APIs surface first. "send WhatsApp message" now returns the WhatsApp Business API at #1.
• Strict matches still rank ahead of synonym-broadened recall, and all weights are tunable without a code change.

2026-06-30Network

Public changelog and roadmap

Added this changelog and a public roadmap, both linked from the site footer, so changes and what's coming next are tracked in the open. (The roadmap page was retired on 2026-08-24; direction now lives at github.com/api-evangelist/roadmap.)