SwitchPDF
All articles
Developer August 11, 2026 5 min read

How to Find Out What APIs a Website Uses

Every site tells you which APIs it calls — you just have to watch the right traffic. Three methods, from fastest to most thorough.

Whether you're evaluating a competitor, documenting a system you inherited, or just curious how a page loads its data, the APIs behind a website are visible if you know where to look.

Method 1: The network tab

Open DevTools, switch to Network, filter to Fetch/XHR, and reload the page. Every API call the page makes appears in the list with its method, URL, status and response.

This is the ground truth, and it's free. The downsides are that it only shows what fires while you watch, you have to do it manually per page, and reading 200 requests to find the 8 that matter is tedious.

Method 2: Look for a published API spec

Many backends serve a machine-readable spec at a conventional path. Worth trying before anything else:

/openapi.json          (FastAPI)
/v3/api-docs           (Spring springdoc)
/swagger/v1/swagger.json  (ASP.NET Swashbuckle)
/api-json              (NestJS)
/api/schema/           (Django REST framework)

When one of these exists you hit the jackpot: every endpoint, every method, and the descriptions the developers wrote themselves. That's the only source that tells you what an endpoint is for rather than what it looks like.

Method 3: Let a tool do both

SwitchPDF Website Analyzer runs both passes for you. The fast scan checks the conventional spec paths and scans the site's JavaScript bundles for API-shaped strings. The optional deep scan loads the page in a real browser and records every request it makes.

For each endpoint you get the method and path, how many times it was called, its status, a ready-to-run cURL command, and the structure of the response — field names and types, nested several levels deep.

Reading the results honestly

The analyzer labels every finding by confidence, and you should respect the labels:

  • Documented — from the site's own spec. Accurate.
  • Observed — the browser watched it happen. It's real.
  • Inferred — the purpose was guessed from the URL. Usually right, sometimes wrong.
  • Referenced — the string appeared in a bundle. Proves nothing about whether it works.

What you will never see

Anything behind a login. Anything on a page you didn't load. Anything triggered by a button nobody clicked. A page-load scan finds the endpoints that power the page you pointed it at, not the whole API surface. Treat the result as a floor, not a ceiling.

One thing you will often find by accident

Sites frequently ship API credentials to the browser — a Basic or Bearer header hardcoded in the frontend bundle. If that's your site, this is your reminder that anything the browser can send, a visitor can read. Move it behind your own backend.

Bottom line

Check for a published spec first, because it answers the "what for" question. Then record the real traffic to see what's actually used. The two together give you a picture neither provides alone.

Related articles