Why use the web UI?
The CLI is great for automation and CI/CD. The web UI is better when you need to:- Explore an API visually with instant feedback
- Debug assertion failures by inspecting response bodies, headers, and status codes side by side
- Export requests to cURL, Fetch, wget, Python, or HTTPie with one click
- Monitor stress tests with live latency percentile charts
- Record real API traffic through a reverse proxy and export it as
.httpfiles - Review persistent run history with drill-down to individual assertions
Starting the server
Flags
| Flag | Default | Description |
|---|---|---|
--port, -p | 4000 | Port to run the server on |
--host | localhost | Bind address |
--open | true | Auto-open browser on start |
--watch, -w | true | Watch for file changes and push updates via WebSocket |
--cors | false | Enable CORS headers (useful when accessing the API from another origin) |
--api-only | false | Serve the REST API only, no SPA frontend |
--read-only | false | Disallow file mutations through the API |
--env, -e | dev | Default environment to activate |
--config | "" | Path to hitspec.yaml config file |
--verbose, -v | false | Enable verbose logging |
--allow-shell | false | Allow shell command execution in request hooks |
--allow-db | false | Allow database assertions |
--log-format | text | Log format: text or json |
--log-level | info | Minimum log level: debug, info, warn, error |
The
--history-db and --no-history flags are available on the hitspec run command. The server always records history to ~/.hitspec/history.db by default.Examples
Workspace layout
The UI is organized into three main areas: a left sidebar, a center request panel, and a right response panel.Top bar
The top bar contains:- Sidebar toggle — show or hide the left panel
- Breadcrumb — shows the active request method and URL
- Command palette trigger — click or press
Cmd+Kto open - Theme toggle — switch between light, dark, and system themes
- Environment selector — dropdown to switch the active environment
- Run All button — executes every request in the active file
Left sidebar
The sidebar has two sections: File tree (top) — Displays all.http and .hitspec files in the workspace as a collapsible tree. Click a file to open it. Use the search icon to filter files by name.
Navigation (bottom) — Links to each view in the application:
| Shortcut | View |
|---|---|
Cmd+1 | Workspace |
Cmd+2 | Stress Test |
Cmd+3 | Mock Server |
Cmd+4 | Contracts |
Cmd+5 | Record |
Cmd+6 | History |
Cmd+7 | Import |
Cmd+8 | Settings |
Cmd+B.
Center: Request panel
When a request is selected, the center panel shows:- URL bar — Displays the HTTP method badge and full URL. Contains a Share button to export the request and a Send button to execute just this request.
- Description — If the request has an
@descriptionannotation, it appears below the URL bar. - Tabs:
- Source — A CodeMirror editor showing the raw
.httpfile content for this request. Edit the source directly and pressCmd+S(Ctrl+Son Windows/Linux) to save changes back to disk. A dot indicator appears on the tab when there are unsaved changes. The file watcher suppresses the reload notification for your own save to avoid UI flicker. - Headers — Read-only view of request headers, with a count badge
- Body — Request body content (JSON, form data, multipart, etc.)
- Assertions — All assertion rules defined for the request, with a count badge
- Captures — Variable captures (name, source, path)
- Source — A CodeMirror editor showing the raw
Right: Response panel
After execution, the response panel shows:- Status bar — HTTP status badge (color-coded), response duration, response size, and a pass/fail indicator
- Tabs:
- Results — Appears after “Run All”; lists every request result with pass/fail status (failed first, then passed, then skipped). Use checkboxes to select results, Shift+click for range selection. Click a result to inspect it.
- Body — Response body rendered in a CodeMirror read-only editor with syntax highlighting, line numbers, and built-in search (
Cmd+F). Large payloads are virtualized for smooth scrolling. - Headers — Response headers as key-value pairs
- Assertions — Each assertion with pass/fail status, expected vs. actual values
- Compare — Compare responses from previous runs side-by-side. A sidebar lists historical results for the current request; select two to see a unified or split diff view with syntax-highlighted additions and removals.
Status bar
At the bottom of the screen, the status bar shows:- WebSocket connection status (green dot = connected)
- Active environment name
- Current file name
- Watch mode indicator (appears when a file change is detected)
- Execution progress or last response time
Running requests
There are two ways to execute requests:Run a single request
Click the Send button in the URL bar, or press
Cmd+Shift+Enter to run only the active request. The response appears immediately in the right panel.- A progress bar showing completed/total requests
- The name of the currently executing request
- A streaming list of completed results with pass/fail status and duration
Environments
Environments let you swap variables (base URLs, API keys, tokens) without editing your.http files.
The environment selector is in the top bar. Select an environment from the dropdown, and all {{variable}} interpolations in your requests will resolve using that environment’s values.
File-level variables (defined with @variableName = value in your .http file) have lower priority than environment variables. This means you can set defaults in your file and override them per-environment.
The active environment is also visible in the status bar and is sent to the server with every execution request.
Export
Click the Share button (arrow icon) in the URL bar to open the export dialog. The dialog generates code for the selected request in five formats:- cURL — Shell command
- Fetch — JavaScript
fetch()call - wget — Shell command
- Python —
requestslibrary - HTTPie — Shell command
Import
Navigate to the Import view (Cmd+7) to convert existing API definitions into .http files.
cURL
Paste a cURL command and convert it to hitspec format.
Insomnia
Paste an Insomnia export JSON to generate
.http files.OpenAPI
Provide a path to an OpenAPI/Swagger spec (YAML or JSON) and an optional base URL.
.http content appears in a preview pane. Copy it to your clipboard or paste it into a new file in your workspace.
Command palette
PressCmd+K to open the command palette. It provides fuzzy search across:
- Actions — Run current file, view keyboard shortcuts
- Navigation — Jump to any view (Workspace, Stress Test, Mock, etc.)
- Files — Open any
.httpor.hitspecfile in the workspace - Requests — Jump directly to a specific request by name, method, or URL
Enter to select, and Escape to close.
Keyboard shortcuts
General
| Shortcut | Action |
|---|---|
Cmd+K | Open command palette |
Cmd+S | Save source editor changes to disk |
Cmd+Enter | Run all requests in the active file |
Cmd+Shift+Enter | Run active request only |
Cmd+? | Show keyboard shortcuts dialog |
Escape | Dismiss errors / close dialogs |
Navigation
| Shortcut | Action |
|---|---|
Cmd+1 | Go to Workspace |
Cmd+2 | Go to Stress Testing |
Cmd+3 | Go to Mock Server |
Cmd+4 | Go to Contracts |
Cmd+5 | Go to Record |
Cmd+6 | Go to History |
Cmd+7 | Go to Import |
Cmd+8 | Go to Settings |
Sidebar
| Shortcut | Action |
|---|---|
Cmd+B | Toggle sidebar visibility |
On Windows and Linux, replace
Cmd with Ctrl for all shortcuts.History
Navigate to the History view (Cmd+6) to browse persistent run history. Every file execution is recorded automatically to a local SQLite database at ~/.hitspec/history.db.
The history view shows a paginated list of runs (20 per page). Each run entry displays:
- File name
- Environment used
- Pass/fail/skip counts with color-coded icons
- Total duration
- Relative timestamp (e.g., “2 minutes ago”)
- HTTP method and request name
- Status code (color-coded: green for 2xx, yellow for 3xx, red for 4xx/5xx)
- Duration
- Pass/fail indicator
- Subject, operator, and expected value for each assertion
- Actual value for failed assertions
- Custom assertion messages
Stress testing
Navigate to the Stress Test view (Cmd+2) to configure and run load tests.
Select a target file
Open a
.http file in the Workspace first. The stress test will target the currently active file.Configure parameters
Set three parameters:
- Concurrency — Number of virtual users (default: 10)
- Duration — How long to run (e.g.,
30s,5m) - Target RPS — Requests per second (default: 100)
- Total Requests — Cumulative count
- RPS — Current requests per second
- P95 Latency — 95th percentile response time
- Errors — Error count
- Latency Percentiles — P50, P95, P99 breakdown
Results
After a stress test completes, a results panel replaces the live dashboard. It shows:- Summary cards — Total requests, average RPS, success rate, and error count
- Latency percentiles — Min, P50, P95, P99, Max, Mean, Standard Deviation (fractional milliseconds)
- Per-request breakdown — A table with each request’s count, success/error split, and individual latency metrics
- Threshold pass/fail — Badges for each configured threshold showing whether it passed or failed
Managing stress profiles
Create, edit, and delete stress profiles directly from the UI:- Create: Configure your desired parameters and click Save as Profile. Enter a name and the profile is saved to
hitspec.yaml. - Edit: Select a profile from the dropdown, modify its parameters, and click Update Profile.
- Delete: Select a profile and click the delete icon to remove it from
hitspec.yaml.
Mock server
Navigate to the Mock Server view (Cmd+3) to start a mock server from your .http files.
Start the server
Click Start. The server reads your
.http files and registers routes based on the defined requests and their response bodies.Recording proxy
Navigate to the Record view (Cmd+5) to capture real API traffic and export it as .http files.
Configure the proxy
Set the Target URL (the real API to proxy to, e.g.,
http://localhost:3000) and the Proxy Port (default: 8081). Optionally enable Deduplicate requests to skip duplicate captures.Send traffic through the proxy
Point your application or HTTP client at
http://localhost:8081 instead of the real API. Every request is captured and displayed in the recordings list with method, path, status code, and duration.Contract testing
Navigate to the Contracts view (Cmd+4) to verify API contracts against a live provider.
Set the provider URL
Enter the URL of the API you want to verify (e.g.,
http://localhost:3000). Optionally provide a state handler script path.Select contract files
The view lists all
.http and .hitspec files in your workspace. Check the files you want to verify, or click Select All.Settings
Navigate to the Settings view (Cmd+8) to configure the application. All settings changes are automatically persisted to the hitspec.yaml config file on disk. If no config file exists, one is created in the workspace root when you save.
Appearance
Switch between Light, Dark, and System themes. The system option follows your OS preference.Request defaults
| Setting | Description |
|---|---|
| Timeout | Default request timeout in milliseconds |
| Follow Redirects | Whether to follow HTTP redirects automatically |
| Validate SSL | Whether to verify SSL certificates |
| Parallel Execution | Execute requests within a file in parallel |
Notifications
Configure webhook URLs for Slack and Microsoft Teams to receive notifications on test failures or successes.Database assertions
Enable database assertion support and configure the connection:- Database Type — PostgreSQL, MySQL, or SQLite
- Connection String — Database connection URL
Database assertions require the
--allow-db flag when starting the server.System info
Displays the hitspec version, Go version, platform (OS/architecture), and build time.Real-time updates
The web UI maintains a persistent WebSocket connection to the server at/api/v1/ws. This connection provides:
- File changes — When a
.httpor.hitspecfile is modified on disk (with--watchenabled), the UI automatically reloads the file tree and re-parses the active file. A “Watch” indicator appears in the status bar. - Execution progress — During a “Run All” operation, per-request progress updates stream to the UI in real time, powering the progress bar and result list.
- Stress metrics — During a stress test, live metrics (RPS, latency percentiles, error count) are pushed to the dashboard via the
stress_updateevent. - Heartbeat — The client sends a
pingevery 30 seconds to keep the connection alive. If the connection drops, it automatically reconnects with exponential backoff (up to 30 seconds).