Skip to main content
The API Client Manager is a browser-based interface for working with hitspec files. It provides a visual environment for editing requests, running tests, viewing responses, stress testing, mock servers, contract verification, and more — all powered by the same engine that runs in your terminal.

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 .http files
  • Review persistent run history with drill-down to individual assertions
Everything you do in the web UI uses the same .http / .hitspec files on disk. There is no separate project format — your files stay version-controlled and CLI-compatible.

Starting the server

hitspec serve
By default, this starts the server on port 4000, opens your browser, and watches for file changes. Pass a directory argument to set the workspace root:
hitspec serve ./tests/api/

Flags

FlagDefaultDescription
--port, -p4000Port to run the server on
--hostlocalhostBind address
--opentrueAuto-open browser on start
--watch, -wtrueWatch for file changes and push updates via WebSocket
--corsfalseEnable CORS headers (useful when accessing the API from another origin)
--api-onlyfalseServe the REST API only, no SPA frontend
--read-onlyfalseDisallow file mutations through the API
--env, -edevDefault environment to activate
--config""Path to hitspec.yaml config file
--verbose, -vfalseEnable verbose logging
--allow-shellfalseAllow shell command execution in request hooks
--allow-dbfalseAllow database assertions
--log-formattextLog format: text or json
--log-levelinfoMinimum 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

# Serve on a custom port without opening the browser
hitspec serve --port 8080 --open=false

# API-only mode for a custom frontend or scripted access
hitspec serve --api-only --cors --port 3001

# Read-only mode for shared staging environments
hitspec serve --read-only --env staging

# Verbose JSON logs for production debugging
hitspec serve --log-format json --log-level debug

# Allow shell hooks and database assertions
hitspec serve --allow-shell --allow-db

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+K to 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
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:
ShortcutView
Cmd+1Workspace
Cmd+2Stress Test
Cmd+3Mock Server
Cmd+4Contracts
Cmd+5Record
Cmd+6History
Cmd+7Import
Cmd+8Settings
Toggle the sidebar with Cmd+B.

Center: Request panel

When a request is selected, the center panel shows:
  1. 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.
  2. Description — If the request has an @description annotation, it appears below the URL bar.
  3. Tabs:
    • Source — A CodeMirror editor showing the raw .http file content for this request. Edit the source directly and press Cmd+S (Ctrl+S on 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)

Right: Response panel

After execution, the response panel shows:
  1. Status bar — HTTP status badge (color-coded), response duration, response size, and a pass/fail indicator
  2. 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.
The workspace split between request and response panels is resizable — drag the divider to adjust. Your preferred ratio is saved across sessions.

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:
1

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.
2

Run all requests in a file

Click the Run All button in the top bar, or press Cmd+Enter. This executes every request in the active file sequentially. A progress bar shows completion status with per-request pass/fail indicators streaming in real time via WebSocket.
During execution, the response panel shows a live progress indicator with:
  • 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
After completion, the Results tab appears with a full summary. Click any result to drill into its response body, headers, and assertions.
Press Escape to dismiss error states in the response panel.

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
  • Pythonrequests library
  • HTTPie — Shell command
All environment variables and file-level variables are interpolated into the exported code. You can copy to clipboard or download as a file.

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.
The generated .http content appears in a preview pane. Copy it to your clipboard or paste it into a new file in your workspace.

Command palette

Press Cmd+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 .http or .hitspec file in the workspace
  • Requests — Jump directly to a specific request by name, method, or URL
Use arrow keys to navigate, Enter to select, and Escape to close.

Keyboard shortcuts

General

ShortcutAction
Cmd+KOpen command palette
Cmd+SSave source editor changes to disk
Cmd+EnterRun all requests in the active file
Cmd+Shift+EnterRun active request only
Cmd+?Show keyboard shortcuts dialog
EscapeDismiss errors / close dialogs
ShortcutAction
Cmd+1Go to Workspace
Cmd+2Go to Stress Testing
Cmd+3Go to Mock Server
Cmd+4Go to Contracts
Cmd+5Go to Record
Cmd+6Go to History
Cmd+7Go to Import
Cmd+8Go to Settings
ShortcutAction
Cmd+BToggle 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”)
Click a run to expand it and see individual request results. Each result shows:
  • HTTP method and request name
  • Status code (color-coded: green for 2xx, yellow for 3xx, red for 4xx/5xx)
  • Duration
  • Pass/fail indicator
Click a result to expand its assertion details, showing:
  • Subject, operator, and expected value for each assertion
  • Actual value for failed assertions
  • Custom assertion messages
Selection and bulk actions: Use checkboxes to select multiple results (Shift+click for range selection). When exactly two results are selected, a Compare (2) button appears to diff their response bodies. Response comparison: You can also compare responses over time using the Compare tab in the response panel. When viewing a request, switch to the Compare tab to see a sidebar of all previous runs for that request. Select two runs to see a side-by-side or unified diff of their response bodies. The diff computation runs in a background Web Worker to keep the UI responsive. Use the Clear All button to delete all history, or the trash icon on individual runs to remove them.
Clearing history is permanent and cannot be undone.

Stress testing

Navigate to the Stress Test view (Cmd+2) to configure and run load tests.
1

Select a target file

Open a .http file in the Workspace first. The stress test will target the currently active file.
2

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)
You can also select a saved Stress Profile from the dropdown to populate these fields automatically. See Stress Profiles for details.
3

Start the test

Click Start. Live metrics stream in via WebSocket with a polling fallback every 3 seconds.
While running, the dashboard shows:
  • Total Requests — Cumulative count
  • RPS — Current requests per second
  • P95 Latency — 95th percentile response time
  • Errors — Error count
  • Latency Percentiles — P50, P95, P99 breakdown
Click Stop Test to end the test early.

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
Click Run Again to return to the configuration view.

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.
1

Set the port

Enter the port number for the mock server (default: 8080).
2

Start the server

Click Start. The server reads your .http files and registers routes based on the defined requests and their response bodies.
3

View routes

While running, the view shows all registered routes with their HTTP method, path, status code, and content type.
Click Stop Server to shut it down.

Recording proxy

Navigate to the Record view (Cmd+5) to capture real API traffic and export it as .http files.
1

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.
2

Start recording

Click Start Recording. The proxy starts listening on the specified port.
3

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.
4

Export

Click Export to generate .http file content from the captured traffic. Copy it to your clipboard or save it to a file.
Use Clear to remove all captured recordings, or Stop to shut down the proxy.
The exported content persists in the UI even after stopping the proxy, so you will not lose your export if you stop recording.

Contract testing

Navigate to the Contracts view (Cmd+4) to verify API contracts against a live provider.
1

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.
2

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.
3

Run verification

Click Verify Contracts. Each contract file is verified against the provider. Results show pass/fail/skip counts and per-interaction details including duration and error messages.

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

SettingDescription
TimeoutDefault request timeout in milliseconds
Follow RedirectsWhether to follow HTTP redirects automatically
Validate SSLWhether to verify SSL certificates
Parallel ExecutionExecute 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 .http or .hitspec file is modified on disk (with --watch enabled), 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_update event.
  • Heartbeat — The client sends a ping every 30 seconds to keep the connection alive. If the connection drops, it automatically reconnects with exponential backoff (up to 30 seconds).
The connection status is always visible in the bottom-left corner of the status bar: a green dot means connected, a pulsing red dot means disconnected and reconnecting.