Example entry
id"openai"
authType"bearer"
baseUrlapi.openai.com
endpoints7 defined
status● Live · 117ms
score72%

Our Philosophy

APIs should be as readable
to agents as to humans.

We built API Map because the fastest-moving builders in software right now aren't humans typing at a keyboard — they're AI agents operating at runtime, and the infrastructure they need to reason about APIs simply doesn't exist yet.

1,349
APIs catalogued
3,158
endpoints documented
924
verified live today
14
categories
01

01

Human docs weren't designed for machines. We fixed that.

Traditional API documentation is written for a human sitting in a browser: narrative prose, interactive playgrounds, marketing copy, changelog digressions. It's genuinely good at what it does — but an AI agent querying an API at runtime doesn't need any of that. It needs a base URL. An exact auth header format. A precise list of endpoints and what they return. That's it.

When an agent has to parse unstructured docs to understand an API, things break. Wrong auth format. Stale endpoint path. Misunderstood rate limit. The failure mode is silent and expensive — a wasted LLM call, a failed tool use, a hallucinated parameter that cascades into bad output.

Traditional docs
# Authentication

To authenticate, pass your API
key as a Bearer token in the
Authorization header. Keys are
prefixed with sk- and can be
generated in the dashboard.

Rate limits vary by tier and
endpoint. See rate limit docs
for details...

→ agent guesses at format
→ silent auth failures
→ stale after doc updates
API Map structured data
{
  authType: "bearer",
  authExample:
    "Authorization: Bearer sk-...",
  baseUrl:
    "https://api.openai.com/v1",
  rateLimit: "3,500 RPM",
  verifiedStatus: 200,
}

→ exact, copy-ready, verified

Structured data isn't more convenient for agents — it's the difference between reliably calling an API and guessing at one.

Every entry in API Map is a structured object: base URL, auth type, exact auth header example, endpoints with methods and descriptions, pricing model, rate limits, and a machine-readable markdown mirror. No noise. No narrative. Just the signal an agent needs to act.

02

02

Honesty about cost and reliability is non-negotiable.

Most API directories are directories in the marketing sense — promotional listings with curated screenshots and testimonial quotes. Pricing is buried or omitted. Reliability is assumed. It's useful for discovery; it's nearly useless for decision-making.

We think builders deserve better data. Here's what every entry carries:

Signal Typical directory API Map
Endpoint status Assumed working Live-verified · HTTP status + latency
Pricing Link to pricing page Structured model, tiers, unit cost, free quota
Latency Not measured Measured p50/p95 from real probes
Free tier Mentioned or not Boolean flag + quota details
Auth format Described in prose Exact copy-ready header string
Builder score No ranking criteria 0–100% across pricing, latency, depth

The builder-friendly score exists for the same reason. We're not ranking APIs by who pays for placement — we score them on three things a builder actually cares about: how easy they are to start with, how fast they respond, and how much they offer. No ads. No sponsored listings. No editorial opinion.

03

03

The best APIs serve the developer who integrates them and the agent who calls them.

The shift happening in software right now isn't a replacement of developers — it's a multiplication. A single developer can deploy agents that make thousands of API calls per minute across dozens of services. The developer still makes the architectural decisions: which APIs to use, how to authenticate, what to do when a call fails. The agent handles execution.

This creates a requirement most API documentation ignores: the same information needs to be useful at two different layers simultaneously.

Design time
👩‍💻
Developer
Evaluating, choosing,
configuring
Which API is most reliable?
Does it have a free tier?
How does auth work?
What's the rate limit?
handoff
Runtime
🤖
Agent
Constructing, calling,
handling responses
Exact base URL to call
Copy-ready auth header
Endpoint paths + methods
Rate limit to stay under

Design time is for humans. Runtime is for agents. Good API documentation has to work at both.

API Map is built for this handoff. The browsable UI with search, filters, and comparison tools serves the developer making choices. The structured JSON dataset, per-API markdown pages, and MCP server serve the agents and tools operating on those choices downstream.

04

04

Open by default. Composable by design.

We believe that infrastructure for AI-first development should be radically open. Not because openness is philosophically pure — but because the developer ecosystem moves faster when data flows freely, and that speed benefits everyone building on top of it.

📄
Machine-readable JSON
The full dataset is available as a structured JSON endpoint. Any LLM, tool, or script can consume it directly — no scraping, no parsing, no guesswork.
📝
LLM-ready Markdown
Every API has a companion .md file optimized for context window injection — compact, structured, zero HTML noise. Drop it straight into a system prompt.
🔌
MCP Server
Query the full directory from any MCP-compatible agent or IDE. Natural-language API lookup, in-context, without opening a browser or writing a search query.
🔗
Stable Deep Links
Every API has a permanent, shareable URL. Works equally well as a bookmark for a developer or as a context reference injected by an agent.

The formats aren't opinionated about which LLM or agent framework you're using. OpenAI, Claude, Gemini, local models — the data is the same. Whatever you're building with, the API intelligence should travel with you.

05

05

Where this is going.

The 1,349 APIs in this directory are a starting point, not a destination. The deeper goal is a living infrastructure layer — one that keeps endpoint status current, tracks pricing changes as they happen, surfaces new APIs as they become relevant, and gets more useful as the agent ecosystem matures.

We think the next generation of developer tooling will look less like documentation and more like a queryable knowledge graph: something an agent can reason over, compare across, and act on without a human in the loop. API Map is an early attempt to build that substrate — not for any one agent or framework, but for the ecosystem as a whole.

If that resonates with you, the data is yours to use.

Start building.

Browse the directory, explore the pricing comparison, check endpoint health, or pull the raw dataset directly into your stack.