API Directories and Discovery Tools for Developers

An API directory can help you find a service to add weather, payments, maps, search, messaging, or other data to an app. A listing is only the beginning, though. The directory may be community-maintained, the API may require an account, and the documentation may not tell you everything about quotas, commercial use, or data licensing.

This guide focuses on practical places to discover APIs and a repeatable way to evaluate them before you build an integration. For ready-to-use examples, see our guide to free APIs for developers. If you are specifically building a weather feature, compare the directory results with the weather forecast API guide, whose provider details should be checked against current documentation before use.

Which API directory should you use?

Start with the type of discovery you need:

Your task	Start here	Why
Find OpenAPI descriptions for known services	APIs.guru and its OpenAPI Directory repository	Useful when you want machine-readable definitions to inspect, import, generate a client, or compare endpoints
Browse hosted collections and try requests	Postman Explore	Public collections can help you understand request examples and workflows before writing client code
Compare commercial and hosted providers	RapidAPI API Hub	A marketplace can centralize provider discovery and access, but it also adds platform, account, and billing considerations
Look for small public or free services	Public APIs, the public-apis GitHub list, and API List	Community catalogs are broad starting points for experiments, prototypes, and learning
Search a specific vendor's ecosystem	Google APIs Explorer or Microsoft Graph Explorer	First-party explorers are better than a general directory when your app already depends on that platform

No directory is a guarantee that an API is free, stable, secure, or suitable for production. Treat directory entries as leads and verify the provider's own documentation before choosing one.

1. APIs.guru and the OpenAPI Directory

APIs.guru is a directory of web API definitions. Its companion OpenAPI Directory repository describes itself as a directory of REST API definitions in OpenAPI 2.0 and 3.x formats. This makes it a useful choice when your immediate goal is to inspect an API contract rather than browse marketing descriptions.

Use it to:

• Check whether a service publishes an OpenAPI definition.
• Inspect paths, parameters, authentication schemes, and response shapes.
• Import a definition into tools that understand OpenAPI.
• Generate a starting client or mock server, then compare the generated result with the provider's documentation.

Do not assume that a definition is complete or current just because it is machine-readable. Check the definition's version and update history, compare it with the provider's current reference, and test authentication and error responses in a non-production environment. The OpenAPI specification explains the format, but it does not promise that an API provider implements every documented detail correctly.

2. Postman Explore

Postman Explore is useful when you want to find public collections and see example requests. A collection can reveal the intended headers, variables, request body, and response flow faster than reading a long reference document.

Before copying a collection into your project:

1. Open the provider's official documentation from the collection description or provider website.
2. Replace shared or example credentials with your own environment variables. Never commit a token copied from a public collection.
3. Check that the base URL, API version, scopes, and request examples still match the provider's current reference.
4. Reproduce one successful request and at least one expected failure with a test account or sandbox.

Postman examples are helpful documentation, not a service-level commitment. A collection can be user-submitted, stale, or configured for a particular account.

3. API marketplaces

RapidAPI API Hub is an example of a marketplace that lets developers discover APIs through a central platform. This can be convenient for comparing providers and trying an integration, especially when you need an API for a prototype and want a common request interface.

The convenience has trade-offs. Your application may depend on both the underlying provider and the marketplace's proxy, account, billing, quotas, and terms. Before adopting a marketplace integration, confirm:

• Whether requests are sent directly to the provider or through a marketplace proxy.
• Which party owns support and communicates breaking changes.
• Whether the displayed plan is a trial, a free allowance, or a paid subscription.
• How overages, rate limits, refunds, data retention, and cancellation work.
• Whether you can export credentials and move to the provider's direct API later.

For a small product, portability matters. Keep the provider's API calls behind a small adapter so you can change vendors without rewriting the rest of the application.

4. Community catalogs for prototypes

Public APIs is a browsable community list. The public-apis repository and API List offer other ways to search for public or free APIs. These catalogs are useful for finding an idea, a test data source, or a first implementation target.

They are not a substitute for provider documentation. A listing can lag behind a provider's shutdown, change in authentication, rate limits, license, or commercial policy. Check the provider's own domain, not only the directory entry, and record the date you verified it. A free endpoint may still prohibit commercial use, require attribution, limit redistribution, or restrict automated traffic.

For production work, prefer a provider with:

• Current documentation and a visible change history.
• A stable base URL and versioning policy.
• Clear authentication, quota, pricing, and data-use terms.
• A status page or a support path appropriate to the importance of the integration.
• An exportable response format and a realistic migration path.

A practical API evaluation checklist

After finding a candidate, spend a few minutes checking the details that directories usually omit.

1. Confirm the use case and data rights

Write down the exact data or action your application needs. Then check whether the API covers the required geography, freshness, fields, and retention period. Read the license and terms for commercial use, attribution, caching, redistribution, and user-generated data. “Public” does not mean that every returned record can be republished.

2. Check the contract

Look for an official reference or OpenAPI definition. Confirm the base URL, API version, required headers, authentication flow, pagination, date and timezone conventions, identifiers, and error format. Check whether an SDK is generated or officially maintained; a third-party wrapper may lag behind the HTTP API.

3. Model limits and cost

Record requests per second, daily or monthly quotas, page-size limits, payload limits, concurrency rules, and what happens when the limit is reached. Estimate your expected calls:

daily requests = active users × requests per user × cache-miss rate

Include retries and background jobs in the estimate. Cache data where the provider permits it, use pagination deliberately, and add a budget alert before moving beyond a free allowance.

4. Design for failure

Expect timeouts, 401 or 403 authentication failures, 404 version mistakes, 429 rate limiting, and 5xx provider failures. Set a client timeout, use bounded exponential backoff for retryable failures, and do not retry non-idempotent operations blindly. Store enough request IDs and sanitized error context to diagnose a failure without logging secrets or personal data.

5. Protect credentials and user data

Keep API keys on a server or in a managed secret store when the provider does not explicitly support public client keys. Restrict key scopes and rotate them. Do not put credentials in a public repository, browser bundle, Postman export, screenshot, or issue report. Minimize the personal data sent to an external provider and document the retention and deletion behavior that matters to your users.

6. Test a replacement path

Save a small fixture of permitted, non-sensitive responses and write contract tests for the fields your application uses. Test an empty response, invalid input, throttling, a timeout, and a changed or missing field. This gives you a way to detect provider changes and evaluate another API without starting from zero.

A compact discovery workflow

For an individual project or small team, this sequence is usually enough:

1. Search a general directory to identify three plausible providers.
2. Open each provider's official documentation and remove entries with unclear ownership, stale docs, or unsuitable terms.
3. Compare authentication, quotas, latency expectations, data rights, support, and migration effort.
4. Run a minimal request against a sandbox or low-risk account.
5. Put the chosen integration behind an adapter, cache where allowed, and monitor errors and quota usage.
6. Record the provider, API version, verification date, plan, and replacement candidates in the project documentation.

That process is more durable than relying on a static “best APIs” list. Directories help you discover possibilities; the provider's current contract and your own constraints determine whether an API belongs in your application.

Original article media

The following images were part of the original article and are retained as historical visual references. They are not used as evidence that the linked services are still available: