Docs / Capturing traffic

Import a HAR file

Record a flow in your browser and get a diagram of every API call in it.

A HAR file is a recording of every request your browser made while you used a site, with headers and bodies. Volley turns one into a diagram: a lane for the browser, a lane for each server it talked to, and an arrow for each request and reply with the payloads attached.

The file is read in your browser. It is not uploaded, and secrets are removed before anything becomes part of the diagram.

#1. Record the flow

Open your browser's developer tools before you start the flow you want to capture.

Tools such as Charles, mitmproxy and Playwright can write HAR files too, which is handy for flows that do not run in a browser tab.

#2. Open it in Volley

Any of these opens the import:

• Drop the .har file on the editor.
• Choose Import a HAR in the editor's Share menu.
• Click Import a HAR on the Volley home page.

#3. Pick the requests

The dialog lists every request with its method, address and status. Failed requests that got no response show as failed.

• Filter by typing part of a method, address or status, such as POST, api.example.com or 500. Only requests that match the filter are imported.
• Static assets is off by default, which hides images, scripts, stylesheets, fonts and preflight requests. API calls made with fetch or XHR are never hidden. Turn it on if you need those requests.
• Headers is off by default. Turn it on to include the request line and the useful headers, such as Content-Type, Accept, Location and Idempotency-Key, in each payload.
• Tick and untick requests, or use All and None.

Then click Create diagram from N requests. If the editor already holds a diagram with messages, a second button, Compare with this diagram, runs a drift check instead.

#What you get

• Lanes. Browser, then one lane per host in the order they were first called, named after the host (api.example.com). A port becomes a space, so localhost:3000 becomes localhost 3000.
• Title. The file name, tidied up.
• Requests as Browser -> host: METHOD /path?query, in the order they were made.
• Replies as dashed arrows labelled with the status, such as 200 OK. A request that never got a response is drawn as a lost arrow (-x).
• Request payloads. A JSON body in a json block, a form body in a form block, other bodies as text. A request with no body but a query string gets its parameters as in: Query. With Headers on, the payload is a raw http block with the request line, headers and body.
• Response payloads. JSON as out: JSON, other text as out: Body, and binary responses as a note of their type and size.
• Long bodies are trimmed so the diagram stays readable: 40 lines per body, the first 3 items of each array, and 160 characters per string, each marked with how much was left out.

Here is the start of a small recording of a billing job after import, drawn as Volley draws it:

volley

title: billing run
order: Browser, auth.example.com, api.example.com

// Imported from a HAR file recorded 2026-10-15T17:42:00.000Z

Browser -> auth.example.com: POST /oauth2/token
in: Body
```form
grant_type=client_credentials&client_id=billing-worker&client_secret=<redacted>
```

auth.example.com --> Browser: 200 OK
out: JSON
```json
{
  "access_token": "<redacted>",
  "token_type": "Bearer",
  "expires_in": "900",
  "scope": "invoices:read"
}
```

Browser -> api.example.com: GET /invoices?status=open
in: Query
```params
status: open
```

api.example.com --> Browser: 200 OK
out: JSON
```json
[{ "id": "inv_9001", "total": 4200, "currency": "USD", "due_at": "2026-11-01" }]
```

Rename the lanes to something friendlier with the lane menu's Rename, delete steps you do not need, and add notes.

#What is redacted

Before a request becomes part of the diagram, Volley replaces secrets with <redacted>:

• the headers Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-Api-Key, X-Auth-Token, X-CSRF-Token and X-XSRF-Token;
• any query parameter, form field, JSON key, XML tag or multipart field whose name looks secret: names containing password, secret, token, api_key, authorization, cookie, code_verifier, assertion, private_key or session;
• Bearer and Basic credentials inside text bodies;
• secret parameters inside Location, Content-Location and Referer addresses.

Names that only describe a secret, such as token_type, expires_in and token_endpoint, are kept. Booleans, nulls and empty values are kept.

#Limits

When you pick more than your plan allows, the first ones are imported and the dialog says how many. The command line tool has no limit.