Browse APIs is the catalog with a search box. 367 APIs across 29 categories, listed with what each one does, what it costs, and a link to its reference page.
Its job is discovery: finding out that something exists before you build it yourself. A surprising share of the work in an application — validating an email, parsing an address, converting a currency, generating a QR code, extracting text from an image — is already an endpoint here, and the browser is how you find that out in thirty seconds rather than after an afternoon.
Searching and filtering
Search matches names and descriptions, so a term describing the problem usually works as well as one describing the endpoint. Searching email surfaces validation, disposable-address detection and deliverability checks together, which is useful when you do not yet know which of the three you want.
Search is fuzzy rather than exact, weighted so a name match beats an id match beats a category match beats a description match, and it matches anywhere in a description rather than only near the start. That last detail is why a plain-English word finds an endpoint whose name shares nothing with it — searching bank reaches SWIFT Code Lookup through its description. A typo of a letter or two still lands.
The category filter narrows to one area of the catalog. Clear filters resets everything, and combining a search term with a category is the fastest way through a catalog this size.
Sorting
When you are browsing rather than searching, four orders are available. The sort control is disabled while a search is active, because a relevance ranking and a sort are two answers to the same question and mixing them helps nobody.
| Recommended | The default. Endpoints your account already uses come first, then the ones most people start with, then the fastest |
| Name A–Z | For when you know roughly what it is called |
| Fastest | By typical latency — useful when the call sits in a request path |
| Lowest cost | By credits per call |
Recommended putting your own endpoints first is worth knowing, because it means the browser looks different on your account than in a screenshot: the things you already call are at the top.
There is also a grid/list toggle. List view fits more on screen and is the better one for comparing costs down a column.
These are the categories, with how much is in each:
Two habits make the search more useful:
Search the problem, not the product name. You are unlikely to guess that the endpoint you want is called Gibberish Detector; you are very likely to type fake input. Descriptions are indexed, so the second finds the first.
Search the field you need, not the record. If what you actually want is a timezone, searching timezone finds the endpoint that returns it directly, which is cheaper than a broader lookup that happens to include it.
Reading a card
Each entry carries the same four things, and each answers a question you would otherwise have to open a page to ask:
| Name and description | What it does |
| Category | What else is near it — the neighbours are often the better fit |
| Credit cost | What a call costs. Most are 1; rendering, OCR and inference cost more |
| Method | GET or POST, which tells you whether input goes in the query or a body |
Credit cost is the one worth reading properly. It is per call, so an endpoint at four credits used on every page view is four times the traffic of the same feature behind a cache. It is also a rough signal of what an endpoint does: the multi-credit ones are generally doing real work per request (rendering a document, running a model, hitting a paid upstream) rather than reading a table.
From a card you can open the full reference page, which has the parameters, the response fields with their dot-paths, a real sample response, and a working call in four languages.
Straight to a mock
Every card carries a Mock action, which is the browser's one shortcut into building rather than reading: it creates a mock endpoint pre-filled from that endpoint's published example.
That is the fastest route from "this endpoint looks right" to "my front end is calling something shaped like it" — you get a realistic response body without spending a credit or waiting for the integration to be real.
The action is disabled on file-upload endpoints, and says why: those take multipart input that a mock has no way to stand in for.
Deciding between two endpoints
When several endpoints look similar, three things separate them faster than reading both pages end to end:
Credit cost. A cheaper endpoint that answers your question is the right one. If the expensive one is doing more work, its page says what.
Response fields. The reference page lists every field with its type and an example. Scanning that list tells you in seconds whether the field you actually need is in there — which is the real question, and not always the one the description answers.
Premium markers. Fields your plan does not include are absent from the response entirely, not zeroed. One whose useful field is premium on your plan is not the one you want yet.
A worked example. Email Validator and Disposable Email Checker both take an address and both tell you something about its legitimacy, and the descriptions do not obviously separate them. The response fields do: one reports syntax, domain and deliverability, the other answers a single question about the domain's provider. If you are gating signups you probably want the first; if you already validate format yourself and only want to block throwaway domains, the second is cheaper and its answer is easier to act on. Reading two field lists settles it in under a minute.
What is in this catalog
The browser shows the APIs available to your account on this product. That set is not
universal: each product exposes the part of the catalog relevant to it, and calling an endpoint
outside it returns 404 rather than an error explaining that it exists elsewhere. If a reference
you followed from outside the dashboard 404s, that is usually why — see errors.
New endpoints appear here as they ship. Nothing needs to be enabled on your account first, and an existing key can call a new endpoint the day it launches — which is also why key restrictions are a deny-list worth revisiting; see API keys.
From browsing to shipping
The browser is the first step of a short loop:
- Find it here. Search the problem, compare the two or three candidates by cost and fields.
- Read the fields. The reference page tells you whether the response actually contains what your code needs.
- Run it with your real input.
- Keep what works — the call, with the key kept out of it.
Skipping step two is the common mistake. An endpoint that sounds right and returns a shape you cannot use costs an afternoon; the field list costs a minute.
Next
All sources is the same catalog in the docs, grouped by category and linking to every reference page, and quickstart turns one into something working.