Internal API
An internal API is an HTTP endpoint that a website's own pages call, often with JSON or GraphQL. It is not documented as a public API. The data a page shows often arrives through one of these calls. Most sites do not promise that these endpoints will stay the same.
How it works
A page loads and its JavaScript calls an endpoint with fetch or a similar method. The endpoint returns data, usually as JSON. The page renders that data into the layout. The HTML the page first served may hold little of the content.
| Public API | Internal API | |
|---|---|---|
| Documented for outside developers | Yes | Usually not |
| Stability promise | Stated by the provider | None stated |
| Use terms | Set in the API terms | Covered by the site's general terms |
Why it matters for AI agents
An internal API is often the real source of a page's data, so it is a useful target for a tool. It is also undocumented. The owner can change or remove it at any time, so a tool built on it needs regular checks. Wield checks its public read recipes every day when they can run from a server.
Wield and internal APIs
Wield's recipes are small JSON files that describe the requests a site's own pages make. Each recipe lists the origins it may call. Before you rely on a recipe, read the site's terms and the recipe's tos.notes, which list known restrictions. No site endorses or partners with Wield because a recipe exists.
Related terms
FAQ
Is using an internal API allowed?
That depends on the site. Read its terms of service. Wield does not give legal advice. Recipes note known restrictions in plain words, but the site's own terms are the rule that applies.
How do I find a site's internal API?
Wield's recorder captures the network calls of one task in your browser. It strips cookies, auth headers, tokens and every value you typed before anything is sent. Pages make these calls with the Fetch API, which is the usual way to read a JSON response from a site's own server.
Sources
- Fetch API (MDN)developer.mozilla.org