How to find a website's internal API in DevTools

#Before you start

• Use only your own account and your own browser session for this work. Do not copy cookies, tokens or session IDs into notes, files or chat.
• Check the site's terms. Wield's recipes note known restrictions, and a recipe runs only at the pace of a person.
• Prefer a logged-out capture when the task allows it. Logged-out requests carry fewer secrets.

#Capture the task in the Network tab

1. Open the site in Chrome, Edge or another Chromium browser.
2. Open DevTools (on macOS, Command+Option+I; on Windows and Linux, F12 or Control+Shift+I) and select the Network tab.
3. Turn on Preserve log, so requests survive page navigation.
4. Click the Fetch/XHR filter. This hides images, fonts and stylesheets.
5. Do the task once, the way you would normally. For example, search for a product and a price range.

The Chrome DevTools Network reference describes each column and panel in detail.

#Pick the request that returns the data

Click each request and open the Preview or Response tab. Look for a list of results that matches what you see on the page: product names, prices, dates or addresses. Note the request URL, the method, and the parameters the page sent. Ignore requests for analytics, ads and tracking.

#Check whether it needs a token or embedded data

Some requests need a token that the page itself gets. Others have no API call at all, and the data is in the page HTML. Real shapes Wield's recipes use include:

• Embedded JSON in the page, such as Kleinanzeigen's search results.
• Next.js page data (__NEXT_DATA__), such as willhaben's search pages.
• A public JSON gateway that accepts requests from the site's own origin, such as Chefkoch's recipe search.
• A public client key that the site's page exposes, such as IKEA's stock lookup, which Wield reads from the page at run time.
• A script in server-rendered HTML with a state object, such as the Doctolib practitioner search.

If the data is in the page, the recipe reads the page and extracts the values. If a token is needed, the recipe must derive it from the page or from a named cookie, and must not store it.

#Turn it into a recipe

Once you have the request, you have two routes:

• Write it by hand. Describe the site, parameters, steps, output and checks in the recipe format. Then run wield-build lint on the file and test it live. The write-a-recipe guide walks through the fields.
• Record it. On a paid plan, the Wield recorder captures the calls for one task in your browser and strips cookies, auth headers, tokens and typed values on your device. The builder then drafts a recipe. See how to record a site.

If you already saved a HAR file, the repository includes a converter described in tools/har2recipe/RECORD.md. Keep HAR files out of shared folders, because they contain cookies.

#Keep it healthy

Internal APIs change without notice. Wield checks public read recipes every day and marks a recipe degraded when its answer no longer matches. Plan for changes: keep the recipe's checks specific, and re-test after a site update.

#FAQ

#Is it legal to use a site's internal API?

Check the site's terms first. Wield's recipes are for one task at a time that you start yourself, from your own browser. They are not for bulk collection or for polling a site in a loop.

#Do I need the site's official API documentation?

No, but an official API is more stable where one exists. An internal API may change at any time, so it is a good fit for personal, one-off or low-volume tasks.

#What if the request needs a login?

Use your own session in your own browser. Never copy a session cookie or token into a file, a note or a chat. A recipe declares any token it needs, and Wield redacts it from results and logs.