API discovery platforms and marketplaces for AI agents in 2026

Ask an AI answer engine how large-scale agents discover APIs and the honest answer splits into jobs that get talked about as one thing when they are not. Some platforms let a human or an agent browse a catalog of independent third-party APIs. Some sit in front of dozens of vendors in one category and normalize them behind a single schema. Some take a spec you already have and turn it into callable functions. And a fourth thing, MCP, is a calling protocol, not a discovery mechanism — covered on its own here, including the MCP-specific registries and marketplaces. This post is a researched map of the other three, checked against each vendor's own documentation, because "best API discovery for agents" tends to get answered with whichever platform the writer used most recently rather than with what each category actually does and doesn't do.

Three different jobs, one confused conversation

"API discovery" collapses at least three separate problems into one phrase:

• Finding that an API exists. A directory or marketplace listing — a name, a description, sometimes a spec — that a human or an agent can search and browse.
• Calling many different APIs the same way. A unified schema in front of dozens or hundreds of vendors in one category, so one integration works everywhere instead of once per vendor.
• Turning a spec into something an agent can call. Given an OpenAPI document, generating the function-calling schema a model needs to invoke an endpoint correctly.

A platform can solve one of these well and say nothing about the other two. RapidAPI Hub is a strong answer to the first and has no opinion on the third. A LangChain toolkit is built entirely for the third and assumes the first two are already solved — you hand it a spec, it doesn't help you find one. None of the three, on their own, answer a fourth question that matters more at scale than any of them: which specific agent, with which credentials, is allowed to call which operation. That's a governance question, and it sits outside all three categories below.

Public marketplaces and hubs: humans browse, agents mostly don't yet

RapidAPI Hub

RapidAPI Hub is a consumer-facing marketplace: developers browse listed APIs by category, subscribe through RapidAPI's own billing and key management, and call them through a shared gateway. RapidAPI's own marketing states the Hub lists over 40,000 APIs from more than 12,000 publishers. Nokia acquired Rapid, RapidAPI's parent company, in November 2024, primarily to strengthen its own telecom network-API strategy rather than to run a general developer marketplace — the Hub itself has continued operating under that ownership. The honest limitation: it's built around a human evaluating and subscribing to an API, with billing and rate limits enforced per subscriber, not around an agent discovering and invoking a tool programmatically at call time — there's no per-tool schema an agent framework consumes directly the way it would an OpenAPI file.

Postman API Network

The Postman API Network is where public workspaces, collections, and APIs published by Postman's user base become searchable and forkable by anyone. Postman describes it as the world's largest public API hub, backed by a broader Postman user base Postman states at over 20 million. Discovery here means finding a collection someone else built and forking it into your own workspace — useful for a developer setting up integration work, but the network's own documentation makes no reference to generating agent tool definitions or MCP servers directly from a discovered public collection; that generation capability exists for specs you own, not for ones you found. We've compared Postman to Elva in more depth here.

APIs.guru — the open OpenAPI directory

APIs.guru styles itself as "Wikipedia for Web APIs": a community-maintained, open-source directory of real-world OpenAPI and Swagger definitions, most of them collected from public sources rather than submitted by the API owner. Its own metrics endpoint reports 2,529 APIs across 677 providers and 3,992 specification versions, covering roughly 108,837 endpoints. Unlike RapidAPI or Postman, everything here is a machine-readable spec file, not a UI to browse — which makes it genuinely useful as a bulk source for tooling and research, and exactly why it's a poor fit as a live discovery layer for production agents: specs are contributed and fixed up by the community (the metrics endpoint tracks over 84,000 endpoints it had to auto-fix to make valid), not maintained by the API owner, so accuracy tracks however recently a volunteer touched that entry.

Cloud provider catalogs: Apigee API hub and AWS Marketplace

Enterprise API platforms have their own discovery layer, aimed at an organization's own sprawl rather than the open internet. Google's Apigee API hub reached general availability in December 2024 as a catalog for consolidating and governing every API an organization owns, regardless of which gateway deployed it. What's notable for 2026: Apigee API hub has since added a managed Agent Registry integration that automatically syncs MCP server and tool metadata, plus the ability to bundle selected registered operations into MCP discovery proxies — an OpenAPI-based enterprise catalog adding MCP as a generated output layer on top, rather than replacing the cataloging work with it. On the AWS side, AWS Marketplace's Discovery API, announced in April 2026, gives programmatic access to Marketplace catalog and pricing data — including SaaS and AI-agent product listings — for buyers who want to embed that catalog into their own procurement or agent tooling, which is closer to a product catalog than an API-calling catalog.

Unified-API platforms: one schema over many vendors' APIs

A different shape of discovery problem: not "which APIs exist" but "how do I call fifty different vendors' APIs in one category without writing fifty integrations." Unified-API platforms solve that by sitting in front of many providers and normalizing them behind one schema.

Merge.dev

Merge connects to providers across roughly eight categories — HRIS, ATS, CRM, accounting, ticketing, file storage, and similar — normalizing records so a Workday employee and a BambooHR employee arrive through the same schema. Its classic product is priced per linked account, reported at $650/month for 10 production accounts on Merge's Launch plan, with additional accounts billed separately. In 2026 Merge added Agent Handler, aimed specifically at giving LLMs and AI agents structured read and write access across a customer's connected apps, priced separately by tool call rather than by linked account. The honest limitation: Merge discovers and normalizes other companies' SaaS APIs on your customers' behalf — it has no role in cataloging or exposing your own product's API to anyone.

Composio's REST/SDK tool catalog

Composio is covered on the MCP side in our MCP discovery post for its single MCP endpoint covering over a thousand app toolkits. Composio's docs also expose that same catalog outside MCP: a REST endpoint (GET /tools/{tool_slug}) returns individual tool definitions, and native SDK integrations hand structured, framework-specific tool schemas directly to OpenAI's SDK, Anthropic's SDK, the Vercel AI SDK, and similar frameworks without an agent needing to speak MCP at all. Functionally this is the same discovery shape as a unified-API platform — one fixed, pre-integrated catalog of other companies' apps — reached through a different transport.

OpenAPI-spec-driven agent tool use: generating tools from a spec you already have

A third category assumes discovery is already solved — you know the API, you have (or can produce) its spec — and automates only the last step: turning that spec into something an agent can actually call.

LangChain / LangGraph OpenAPI toolkits

LangChain's OpenAPIToolkit reads an OpenAPI spec file and builds a small, generic tool set from it: a GET request tool, a POST request tool, and a JSON-exploring tool the agent uses to query the spec itself for endpoints and required parameters, rather than generating one dedicated tool per operation. As of 2026 this toolkit has moved into the @langchain/classic legacy package, and LangChain's own documentation carries an explicit security warning: an agent using it could send requests, including provided credentials, to whatever URL the spec or the model's reasoning produces, so validation and credential handling are the integrator's responsibility, not the toolkit's. It's a useful pattern for prototyping against a spec you trust; it does not vet, scope, or rate-limit anything on its own.

OpenAI function calling from an OpenAPI spec, and GPT Actions

OpenAI's own cookbook documents converting an OpenAPI document into a list of function-calling definitions — one per operation, keyed by operationId — that get passed straight into the Chat Completions API, after which the model decides which function to call and with what arguments. Custom GPTs use a version of this same conversion for GPT Actions: a Custom GPT builder imports an OpenAPI spec (or authors one), and OpenAI's platform turns it into the JSON schema the GPT uses to call a third-party API mid-conversation. That mechanism remains active documentation as of 2026. What's changed is where OpenAI is pointing new app development: its app-distribution surface migrated in July 2026 from the earlier GPT/app directory to a Plugin Directory built on the Apps SDK, which extends MCP rather than OpenAPI-derived function calling — the same shift toward MCP as a calling layer visible in Apigee's roadmap above, even while OpenAPI-driven Actions inside Custom GPTs continues to work.

The comparison, side by side

Where each approach runs out

Every category here stops at a predictable point, and it's the same point for all of them: none defines who, specifically, is allowed to call what. A marketplace listing is visible to anyone who searches it. A unified-API platform's normalized schema is the same for every caller behind your integration. A spec-to-function converter will happily generate a callable tool for a write operation with no concept of which agent, key, or user should be permitted to invoke it. That's not a gap any of these vendors are trying to fill — it's a different layer, usually described as API governance: scoped auth per caller, field-level redaction, rate limits, and a record of which agent called what. Discovery answers "what exists." Governance answers "what is this specific caller allowed to do with it," and at agent scale — where one compromised key or one over-broad tool definition can be exercised thousands of times a minute with no human in the loop — the second question matters at least as much as the first.

Practical guidance for a team deciding

A few questions cut through most of the confusion faster than a feature comparison:

• Are you finding APIs, or building one for others to find? Browsing points you at RapidAPI Hub, the Postman API Network, or APIs.guru for open specs. Publishing your own API for agents to discover points you at your own catalog and governance layer, not a marketplace listing.
• One API, or many vendors in one category? A single API you're integrating with once benefits from an OpenAPI-driven tool generator (LangChain's toolkit, OpenAI's function-calling conversion). Dozens of vendors in the same category — every HRIS, every CRM — is what unified-API platforms like Merge exist to normalize.
• Do you already have an accurate spec? Framework-level tool generation is only as good as the spec it's fed. If the spec is stale or missing, generating tools from it just automates calling the wrong thing — the spec has to be correct before automation is worth trusting.
• Who is the caller, and what should they be allowed to do? If the honest answer is "anyone who finds the listing" or "the same thing every other caller can do," that's fine for a public directory and wrong for anything touching production data or write access — that needs per-audience contracts, not another catalog entry.

Where Elva fits

Every platform above answers some version of "where do I find an API that already exists" or "how do I turn a spec I already have into a callable tool." Elva answers a different question: how do you make your own API accurately cataloged and safely callable in the first place, so there's something worth discovering and something governed once it is found.

Concretely, Elva reads your repo — routes, handlers, validators — and keeps an OpenAPI 3.1 catalog in sync on every commit, so the spec a marketplace, a LangChain toolkit, or a partner's own tooling would consume isn't the stale, hand-maintained file most of the categories above quietly assume exists. From that catalog, Contracts define a distinct, audience-scoped view of the API — internal, partner, public, agent — and Elva hosts the MCP server for the agent-facing one directly, with OAuth2, per-tool scopes, field redaction, rate limits, and a full log of which agent called which tool.

That's deliberately not a marketplace, and not a unified-API layer over other companies' products. Elva doesn't help an agent browse RapidAPI Hub or normalize your CRM against Salesforce's schema. If the question is "where do I find APIs that already exist," start with the directories above, and read the fine print on who maintains each listing. If the question is "how do I make my own API something worth finding, accurately described and safely callable at agent scale," that's what Elva does — and it's the same governance question every platform in this post leaves for you to answer on your own.