You watched an app make a request in the browser. It works. The data is right there in the Network tab. Now you want that same call as a documented endpoint you can save, mock, and test, without retyping the URL, the headers, and the JSON body by hand.
That gap between “traffic I can see” and “an endpoint I can reuse” is what a HAR file closes. Your browser already records every request and response it makes. Export that recording, hand it to Apidog, and each captured call becomes a real endpoint in your project. This guide walks the whole path: capture a HAR in Chrome DevTools, import it with the right options, and clean up the generated endpoints so the list stays useful. For a wider look at capture workflows, our guide to packet capture tools with Apidog covers the adjacent ground.
You can Download Apidog for free and follow along on the same screens.
What a HAR file is and why captured traffic is worth keeping
HAR stands for HTTP Archive. Per the Apidog docs, a .har file is “a JSON-formatted file used for logging a web browser’s interaction with a site. It records web requests, responses, headers, and other data sent between the browser and server.”
Read that plainly: a HAR file is a full transcript of a browsing session. Every GET, every POST, the request headers, the response bodies, the timing. Because it is JSON, it travels well. You can email it, attach it to a bug report, or feed it to a tool that knows how to read it.
That last part is why it matters here. A captured session is a record of how an API actually behaves in the wild, not how a spec says it should. When you turn that record into endpoints, you get a few things for free:
- A real request shape. The exact URL, query params, headers, and body the app sent, not a guess.
- A real response. The status code and payload the server returned, which you can use as a mock or a test assertion.
- A starting point for documentation. An undocumented internal API becomes a set of named endpoints you can annotate.
This is handy when you inherit a service with no OpenAPI spec, when you are reverse-engineering how a third-party widget talks to its backend, or when you want to reproduce a bug with the exact call that triggered it.
Step 1: capture the HAR in your browser DevTools
The capture happens in your browser, not in Apidog. Chrome and Edge both use the same DevTools, so the steps are identical. Say you want to capture the traffic behind an order-history page.
- Open the page you want to record. Log in first if the API needs a session, since the HAR will carry those requests too.
- Open Developer Tools. Press
F12, orCtrl+Shift+Ion Windows and Linux, orCmd+Opt+Ion Mac. - Switch to the Network tab. This is where DevTools lists every request the page makes.
- Refresh the page, or click through the actions whose traffic you want. Loading the order-history view fires the calls to
/api/orders,/api/orders/{id}, and whatever else the page needs. Each one shows up as a row. - Right-click any request row and choose Save all as HAR with content. Pick a location and save the file, for example
order-history.har. If the menu wording throws you, the Chrome DevTools Network reference documents the same capture and export flow.
That “with content” part matters. It tells DevTools to include the response bodies, not only the request metadata. Without them, your imported endpoints would have request shapes but no example responses.
A quick sanity check before you leave the browser: if you open the .har in a text editor, it is readable JSON. You will see an entries array where each entry has a request and a response object. That is the structure Apidog reads.
One thing to keep in mind. A page load pulls in more than API calls. It also fetches images, stylesheets, and scripts, and every one of those lands in the HAR. You do not have to filter them out in the browser; Apidog gives you a switch to drop them on import, covered next.
Step 2: import the HAR into Apidog
With the file saved, move to Apidog. The importer lives in one place.
- Open your project and go to Settings > Import Data > Manual.
- Select HAR as the format.
- Upload your
.harfile, for example theorder-history.haryou saved a moment ago.
Before you confirm, Apidog shows three import options. They decide how clean the result is, so it is worth understanding each one instead of clicking through.
Option 1: how the BaseURL is handled
Every captured request has a full URL, something like https://api.shop.example.com/v1/orders/123. You get two choices for what to do with the host part:
- Hardcode keeps the BaseURL inside each endpoint’s path. Every endpoint carries the full
https://api.shop.example.comprefix. - Remove (Recommended) strips the BaseURL out so the endpoint path becomes
/v1/orders/123. The host is then managed globally through environment variables.
Take the Remove option unless you have a reason not to. It is the recommended setting for a reason: when the base URL lives in an environment variable, you can point the same endpoints at production, staging, or a local server by switching environments, with no edits to the endpoints themselves. Hardcoding locks every endpoint to the host you happened to capture from, which gets painful the moment you need to test against a different server.
Option 2: excluding static resources
This is the switch that saves you from a cluttered endpoint list. The Static Resource option, set to Exclude, tells Apidog to skip the captured images, CSS, and JavaScript files. A single page load can produce dozens of those, and none of them are API endpoints you want to document.
Turn Exclude on for almost every import. What is left after the filter is the actual API traffic: the JSON calls to /api/orders and friends, not the request for logo.png.
Option 3: generating a test case per endpoint
The third option is Endpoint Case Generation. Turn it ON and Apidog creates a default test case for each endpoint as it imports. A test case is a saved, runnable invocation of the endpoint with the captured values already filled in.
This is a small step that pays off later. If your goal is to test these endpoints, having a ready case per endpoint means you can run one immediately instead of building it from scratch. If you only want documentation for now, you can leave it off and add cases later.
Confirm the import. Apidog reads the HAR, applies your options, and converts the captured browser interactions into API endpoints inside your project. Open the endpoint tree and you will see them grouped and ready.
Here is roughly what one imported endpoint looks like once it lands, using the order call as the example:
GET /v1/orders/123
Host: api.shop.example.com
Authorization: Bearer <token-from-capture>
Accept: application/json
And the captured response Apidog stores alongside it:
{
"id": 123,
"status": "shipped",
"total": 48.5,
"currency": "USD",
"items": [
{ "sku": "TSHIRT-BLK-M", "qty": 2, "price": 19.25 }
],
"createdAt": "2026-07-14T09:31:00Z"
}
That response is real data the server returned, which makes it a solid basis for a mock or a test assertion.
Step 3: clean up the generated endpoints
A HAR import is a fast first pass, not a finished API definition. Captured traffic is messy by nature, so budget a few minutes to tidy the result.
Prune the noise. Even with Static Resource set to Exclude, you may find analytics pings, health checks, or third-party calls you do not care about. Delete the endpoints you will not use so the tree reflects your actual API.
Rename and group. Captured endpoints are named after their paths, which is functional but flat. Give them clear names (“Get order by ID” instead of /v1/orders/123) and organize them into folders that match your API’s structure.
Fix path parameters. A capture of /v1/orders/123 imports as a literal path. If 123 is really an order ID, edit the endpoint so that segment becomes a {orderId} path parameter. That one change turns a single captured call into a reusable endpoint that works for any order.
Scrub secrets before you share. This one is easy to forget. Your HAR captured whatever auth token was live in that session, and it rode along into the headers. Before you commit the project or share it with teammates, move tokens into environment variables and clear captured credentials from the examples. The Stripe docs make the same point about never letting live keys leak into shared artifacts, and a HAR is exactly the kind of artifact that leaks them.
Sanity-check the bodies. If a body is empty where you expected data, you likely exported without “with content.” Recapture using Save all as HAR with content and re-import.
Once the endpoints are clean, they behave like any other endpoint in Apidog. You can document them, generate a mock from each response, and build tests. The guide to writing a test scenario in Apidog picks up naturally from here, and if you want typed client code from these endpoints, see how to generate client code with Apidog.
Variations and honest limits
A few situations come up often enough to call out.
There is no automatic recorder yet
You might expect Apidog to sit in the background and record traffic live, the way a proxy would. It does not, and it is worth being straight about that. The docs state plainly: “Apidog does not currently support the automatic recording endpoint function, but there are plans to support it in the future.”
So the supported path today is exactly the one in this guide: capture with your browser’s DevTools, export the HAR, and import it. The recommended flow the docs describe is to open DevTools while you exercise an endpoint in the browser, export the HAR when you finish, import it into Apidog in one click, then create a test scenario and import all the requests for playback. It is a manual capture step followed by a one-click import, not a live recorder. When the auto-recording feature ships, this section will change, but do not wait on it.
The Apidog Browser Extension is a different tool
There is an Apidog Browser Extension, and it is easy to assume it captures HAR traffic. It does not. The extension lets you use Apidog’s API testing and debugging directly in the browser without opening the desktop client. It is about running requests, not recording them.
HAR capture comes from your browser’s own DevTools, full stop. If you do use the extension for testing, know that the browser imposes limits on it: it blocks certain headers like Cookie, Host, Origin, and Content-Length, it will not send bodies on GET or HEAD requests, and it cannot reach local code or a database behind your machine. For capturing traffic to import, stick with DevTools and the HAR export. For heavier debugging that needs full header control, the Apidog Desktop Client has no such browser-imposed limits.
Other formats import the same way
HAR is one of several formats the same Settings > Import Data > Manual screen accepts. If you already have an OpenAPI or Swagger file, importing that gives you a cleaner result than a capture, because a spec is structured on purpose. Our walkthrough on migrating Swagger API documentation to Apidog covers that route, and if you are coming from Postman, the Postman environments and collection migration guide does too. Reach for HAR when a real spec does not exist and captured traffic is the best record you have.
Automate the workflow with the Apidog CLI
Importing a HAR doesn’t have to be a GUI step. The Apidog CLI has an import command that reads a HAR file directly, which is what you want when the capture happens on a server, when you script the import in a pipeline, or when you let an AI coding agent turn a capture into endpoints:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
# Turn a captured HAR into endpoints in your project
apidog import --project <PROJECT_ID> --format har --file ./capture.har
The --format flag also accepts openapi, postman, wsdl, insomnia, and more, so one command covers most import sources. Once the endpoints exist and you’ve saved them into a test scenario, run that scenario headlessly in CI:
apidog run --access-token $APIDOG_ACCESS_TOKEN \
-t <SCENARIO_ID> -e <ENV_ID> -r cli
Here -t is the saved test scenario id, -e is the environment id (the same environment variables that hold your BaseURL), and -r picks the reporter, cli for console output. Build the scenario with the guide to writing a test scenario in Apidog, then wire both commands into your pipeline with the Apidog CLI CI/CD guide.
FAQ
Which browsers can export a HAR file?
Any Chromium-based browser with DevTools does it the same way, so Chrome and Edge both use the Network tab and the Save all as HAR with content menu item. The Apidog docs cover the Chrome and Edge path specifically. Other browsers have their own export menus, but the label may differ, so match your browser’s own DevTools wording.
My imported endpoint list is huge. What went wrong?
You most likely left Static Resource set to include everything. A page load pulls in images, CSS, and scripts, and all of them land in the HAR. Re-import the file with the Static Resource option set to Exclude, and the list narrows to actual API calls. You can also delete the stragglers by hand afterward.
Should I choose Hardcode or Remove for the BaseURL?
Choose Remove (Recommended) in almost every case. It pulls the host out of each endpoint path so you manage it globally through an environment variable, which lets you swap between production, staging, and local without editing endpoints. That same setup is what a test scenario in Apidog reads when it runs. Pick Hardcode only when you specifically want the full URL baked into each path.
Does the HAR include my auth tokens?
Yes, and that is the catch. A HAR records the real headers sent during the session, so any bearer token or cookie that was live is in the file. Treat a HAR like a secret: do not paste it into a public issue, and after import, move credentials into environment variables and clear them from the saved examples before sharing the project.
Can I skip the GUI and import a HAR from the command line?
Yes. The Apidog CLI’s apidog import --project <id> --format har --file <path> brings a HAR into your project without opening the app, which is what you want when the capture happens on a server or inside a CI job. The GUI still gives you the interactive import options (BaseURL handling, Static Resource filtering) for a one-off capture, so pick whichever fits: the CLI for scripted or agent-driven imports, the GUI when you want to tune the import by hand. After import, apidog run replays the test scenarios you build from those endpoints.
Wrapping up
A HAR file is the bridge between traffic you can see and endpoints you can reuse. Capture the session in your browser’s DevTools with Save all as HAR with content, import it through Settings > Import Data > Manual with Remove for the BaseURL and Static Resource set to Exclude, then spend a few minutes renaming, parameterizing, and scrubbing secrets. What you get is a working set of endpoints you can document, mock, and test.
Ready to turn your next capture into real endpoints? Download Apidog and try it free, no credit card required.
