ProgrammableWeb Shut Down: Where to Find and Vet APIs in 2026

ProgrammableWeb, the site many developers used to find APIs, shut down on October 31, 2022, and nothing took its place one for one. In 2026, you find APIs through a mix of the Postman API Network, RapidAPI Hub, the APIs.guru OpenAPI directory, the public-apis list on GitHub, APIs.io and the APILayer marketplace. None of them vets an API for you. That step is yours, and the checklist below shows how an app studio does it.

This page replaces the old ProgrammableWeb links that still sit in many articles. Dates come from ProgrammableWeb's own shutdown notice. Directory URLs, counts and GitHub stars were checked on October 17, 2026.

Disclosure: App369 builds Flutter and Firebase apps and integrates third-party APIs for clients. We have no commercial relationship with any directory listed here, and none paid to be on this page.

What happened to ProgrammableWeb

ProgrammableWeb announced on October 10, 2022 that, after 17 years, it would shut down operations on October 31. It first launched in 2005 and was later acquired by MuleSoft. Its API directory had grown to over 24,000 entries, and its API University series had over 800 articles. In the notice, the staff wrote that the MuleSoft blog and resource center "will continue to host the most popular and valuable content that was produced by ProgrammableWeb." The notice is archived at the Wayback Machine.

What the old addresses do today

We checked these on October 17, 2026.

If you edit an article that links to ProgrammableWeb, swap the link for this page, or for a Wayback copy if you are citing a specific old article.

ProgrammableWeb API directory: the closest alternatives in 2026

Notes on the table:

• All of these returned a normal page on October 17, 2026. That is not a quality rating.
• The public-apis list used to have a companion JSON endpoint, api.publicapis.org. It no longer responds, so do not build on it.
• Prices and listing fees are left out because they change often. Check each site before you list an API or rely on a paid plan.
• A directory entry can be out of date. Always confirm details on the provider's own site.

Which one to start with

1. You need a spec to generate code or tests. Start with APIs.guru, then look at the provider's own docs.
2. You want to try calls in minutes. Start with the Postman API Network.
3. You want one place to compare paid APIs. Look at RapidAPI Hub or the APILayer marketplace, and read the terms.
4. You want free APIs for a prototype. Start with the public-apis list. Do not ship a product on a free hobby API without a plan B.
5. You want to find APIs by topic. Try APIs.io, but expect gaps.

How to vet an API before you build an app on it

A directory listing says an API exists. It does not say the API will still be there next year. Run this checklist before you commit, and write down the answers.

1. Docs and spec. Are there current docs, working examples and an OpenAPI spec? An API with no spec is harder to test and to replace. Check the date of the last docs update.
2. Authentication. Does it use OAuth 2.0 or API keys? Can you rotate keys without downtime? Can you scope keys to the least access needed?
3. Rate limits. What are the limits per second, minute and month? What happens when you exceed them: an error, a throttle or a surprise bill? Multiply the limit by your expected users, not by your test traffic.
4. Pricing tiers. What does the free tier include? What does your expected volume cost? Look for per-call fees, overage rates and minimum commitments.
5. Uptime and support. Is there a public status page, an incident history and an SLA? A free API usually has no SLA. A paid one should state it in writing.
6. Versioning and deprecation. Is the version in the URL? How much notice does the provider give before it removes a version? A provider with no written policy is a risk.
7. Terms of use. Can you use the data commercially? Can you cache or store it, and for how long? Can you show it in a mobile app? Does the license restrict competing products?
8. Data and privacy. What user data do you send? Where is it processed and stored? Does the provider act as your processor under a data processing agreement? If you handle health, payment or children's data, check this first.
9. Who owns it. Which company runs it, and was it acquired or renamed recently? Ownership changes are a common cause of changed terms and shutdowns. RapidAPI Hub is an example: Nokia announced the acquisition of Rapid's technology in 2024.
10. A shutdown plan. If this API disappears in 90 days, what do you do? Name a second provider, or decide you can live without the feature.

Build so you can swap a provider

• Route calls through your backend. Do not call a third-party API straight from the mobile client. Your backend can change providers, add caching, and enforce limits. A change in the backend does not need an app store review. A change inside the app binary does.
• Never ship secret keys in the app. Anything inside an app binary can be extracted. Keep secrets on the server, in a secrets manager, and give the app only short-lived tokens issued by your own backend.
• Wrap each provider behind your own interface. Your app code asks for "send email" or "get exchange rate". Only one module knows which vendor does it.
• Store the raw responses you need. If the terms allow it, keep a copy of the data your product depends on, so a shutdown does not erase your history.
• Monitor the dependency. Alert on errors and slow responses from each external API, so you see a problem before your users do.
• Test the failure path. Turn the API off in a test and check that the app shows a clear message instead of a blank screen.

For key handling in the newer MCP and AI tool world, see our guide to API keys vs OAuth for MCP servers. For a similar story about a dependency that closed, see Parse and Kinvey alternatives and the Firebase Dynamic Links shutdown.

API documentation: what good docs contain

ProgrammableWeb ran many pieces on documentation, and editors still link to them. The short version, from the side of the team that has to build on the API:

• A quickstart that works. One page that gets a first successful call running in a few minutes, with copy-paste code.
• Authentication, explained once and clearly. How to get a key or token, how to rotate it, and what each scope allows.
• Every endpoint with a real request and response. Not only field lists. Show a full example body for both.
• Error codes and what to do about them. Which errors are safe to retry, and which mean the request is wrong.
• Rate limits and pricing in the docs. The numbers, not "fair use".
• A changelog and a versioning policy. Dated entries, and how much notice you get before a breaking change.
• An OpenAPI spec you can download. It lets teams generate clients, mocks and tests instead of copying by hand.
• A sandbox or test mode. So integrators can test without touching real data or money.

If an API you are vetting misses three or more of these, budget extra time for the integration.

API-first development in one paragraph

API-first means you design and agree the API contract before anyone builds a client or a server. In practice, the team writes an OpenAPI description first, reviews it with the people who will call it, and then generates mock servers, tests and client SDKs from it. Mobile and web teams can start against the mock while the backend is built. The specs in the APIs.guru directory are examples of this kind of machine-readable contract. For an app, it means fewer surprises late in the project, because the shape of every request is settled up front.

Where ProgrammableWeb's articles and API guides went

The shutdown notice says the MuleSoft blog and resource center would keep the most popular content. In our check, the old mulesoft.com/programmableweb address redirects to the MuleSoft blog home, so there is no one-to-one map from the old articles to new addresses. We did not find an official archive of the full 24,000-entry directory.

Your options for a specific old page:

• Search the MuleSoft blog for the article title.
• Use the Wayback Machine. Paste the old address into it. Link to the archived copy, not to the dead site.
• For API design practice, go to the OpenAPI Initiative, which maintains the OpenAPI Specification.

Need a hand?

App369 is Simon Dziak's studio. He builds and runs Workspace369, a production Flutter and Firebase SaaS.

If you are connecting an app to a third-party API, such as Stripe, a CRM or a data provider, the closest fixed-price offer is API Integration, $1,200 fixed price, 5 business days after API docs and test credentials for both systems arrive.

• An integration that broke after a provider changed or shut down: the App Fix Ticket diagnoses one issue for $450 and fixes it for $1,200, both fixed price.
• Need a new web app that depends on several APIs: the Web App MVP Sprint starts with a $450 scoping step and the build starts from $6,000. It is for web apps, not native mobile apps, so if you need a mobile app, get in touch first.