Public APIs
All posts

API Response Time: What 99 Public APIs Actually Do

Quick answer: A good API response time is under 200 ms of server processing, and under about 500 ms end to end for a user-facing call. Above one second, people notice. We timed 99 live public APIs: the median answered in 446 ms in total, of which the server's own work was 195 ms. Only 33 came back in under 200 ms.

Every article on this topic repeats the same thresholds from first principles. None of them measure the APIs you are actually about to call, so we did.

What we measured

We run a directory of public APIs. Of the 1,603 live APIs we list (published, not archived, on 13 October 2026), 244 need no key and allow browser calls (CORS). On 13 October 2026 we built a real request for 115 of them and called each one six times, 1.5 seconds apart, with a fresh connection every time, the way a simple script or serverless function does.

100 answered consistently. We dropped one more, a static CDN file that timed out mid-download, which leaves 99 APIs and 589 timed requests. For every request curl recorded DNS lookup, TCP connect, TLS handshake, time to first byte and total time.

One caveat matters more than any other: all requests came from a single machine in southern Brazil. Most of these APIs are hosted in Europe or North America, so the same test from Frankfurt or Virginia would be faster. That is why we split the numbers into network time and server time below.

What is a good response time for an API?

Here is the distribution across the 99 APIs, using each API's median of six calls:

| Percentile | Total response time | Server time only | |---|---|---| | p50 (median API) | 446 ms | 195 ms | | p75 | 717 ms | 324 ms | | p90 | 953 ms | 572 ms | | p99 | 2,316 ms | 2,216 ms |

"Server time" is time to first byte minus the connection and TLS setup, which is roughly how long the API took to think before it started answering.

Against the usual thresholds:

| Total time | APIs | Share | |---|---|---| | Under 200 ms | 33 | 33% | | 200 to 500 ms | 25 | 25% | | 500 ms to 1 s | 33 | 33% | | 1 s or more | 8 | 8% |

So a reasonable working answer: under 200 ms of server time is good, and half of free public APIs manage it (51 of 99). Under 100 ms is excellent (34 of 99). A total above one second is slow, and only 8 of 99 were.

Why does distance matter more than code?

The biggest single factor in our data was not the API's code. It was how far away it was.

70 APIs answered from a server close to us, with a TCP handshake under 60 ms, almost always a CDN edge such as Cloudflare. Their median total was 253 ms. 29 APIs answered from a distant origin, with a median handshake of 222 ms. Their median total was 740 ms, nearly three times slower, even though their median server time (235 ms) was not much worse than the nearby group's (161 ms).

The reason is round trips. A fresh HTTPS request needs one round trip for TCP, at least one more for TLS, and one for the request itself. At 220 ms per round trip, you have spent two thirds of a second before the server does any work. Open-Meteo is a good example: its server needed 182 ms, but the whole request took 740 ms because the handshakes went to Europe and back.

The fastest APIs in the sample were all CDN-backed:

  1. Currency API: 63 ms, a static JSON file on jsDelivr.
  2. Nominatim: 81 ms.
  3. GitHub Readme Stats: 96 ms once warm.
  4. Coinpaprika: 108 ms.
  5. Rick and Morty: 110 ms.
  6. US Weather (weather.gov): 113 ms.

The slowest were slow on the server, not the network. PoetryDB spent 2.1 seconds working before its first byte, and the Disney API took 5.8 seconds for five characters.

Is the first call slower?

Often, yes. For 29 of the 99 APIs, the slowest call was more than twice the median. The worst cases were cold starts: GitHub Readme Stats took 3.3 seconds on the first call and 96 ms after that, and Open5e went from 3.5 seconds to 132 ms. Both look like serverless functions or caches waking up.

Across all 589 requests, the median was 431 ms but p99 was 3.4 seconds. If you only test an API once, you are measuring luck. Time ten calls and look at the slowest.

Does the category of API matter?

A little, and mostly because of hosting rather than subject matter. Medians for the categories with at least five APIs in the sample:

| Category | APIs timed | Median total | |---|---|---| | Geocoding | 8 | 257 ms | | Development | 10 | 275 ms | | Games & Comics | 15 | 312 ms | | Animals | 7 | 366 ms | | Books | 7 | 499 ms | | Video | 5 | 516 ms | | Art & Design | 6 | 679 ms |

The samples are small, so treat these as a hint, not a ranking.

How do you make a slow API feel fast?

You cannot change someone else's server, but most of the cost we measured is avoidable on your side:

  1. Reuse connections. Every call in our test opened a new connection. A client that keeps the connection alive skips the TCP and TLS round trips, which were most of the time for the 29 distant APIs.
  2. Cache what does not change. Exchange rates, country lists and holidays change daily or yearly. Our survey of what public APIs send for caching shows which ones tell you how long to keep a response.
  3. Call from close to the API. A serverless function in the API's region turns a 220 ms round trip into a few milliseconds.
  4. Set a timeout and expect the tail. With p99 at 3.4 seconds, a 2-second timeout plus one retry is safer than waiting forever.
  5. Watch for rate limits. Agify and Nationalize returned 429 Too Many Requests after three calls each, which is why they are missing from the results. Our guide to API rate limiting covers how to back off.

If you depend on an API in production, track its latency over time rather than once. Our comparison of API monitoring tools covers the free options.

How did we measure this?

Date: 13 October 2026. Corpus: the 244 keyless, CORS-enabled APIs among the 1,603 live public APIs in our directory (status published, archived false). Sample: 115 with a known working endpoint, each called six times with curl, 1.5 seconds apart, new connection each time, from one machine in southern Brazil. Excluded: 15 APIs that did not return a success at least four times (rate limits, 403 and 404 errors, and timeouts), and one CDN file that timed out mid-download. Each API's figure is the median of its six calls. Server time is time to first byte minus TCP and TLS setup. We will re-run this monthly.

Frequently asked questions

What is a good response time for an API?

Under 200 ms of server processing time is good, and under 100 ms is excellent. End to end, under about 500 ms feels responsive in an app, and above one second users notice the wait. In our test of 99 public APIs, the median total was 446 ms and the median server time was 195 ms.

What is the difference between latency and response time?

Latency usually means the network delay, the time for data to travel between you and the server. Response time is the whole thing: network round trips, connection setup, server processing and downloading the body. In our data, network and connection setup were about 60% of the typical response time.

How do you measure API response time?

Use curl with the -w option to print time_connect, time_appconnect, time_starttransfer and time_total for a request. Run it several times, because the first call is often much slower. For ongoing measurement, use an API monitoring tool that checks from several regions.

Why is my API slow only on the first request?

Usually a cold start: a serverless function spinning up, a cache filling, or a database connection opening. DNS lookup and the TLS handshake also add time to the first call on a new connection. Two APIs in our test took over three seconds on the first call and under 150 ms afterwards.