A desktop API client that ships as one file

ResponderHTTP is an API client for Windows and Linux. Type a URL, choose a method, add headers, parameters, a body and authentication, and send. You get the status code, the response headers, the body with syntax highlighting, and a timing breakdown showing where the time actually went — DNS, connect, TLS, first byte, total.

It ships as a single executable. The HTTP, WebSocket and gRPC engine is libcurl, compiled into the app, so there is no curl to install, no runtime to add and no system SSL library to keep up to date.

• Requests — every common method, query parameters, headers, form and raw bodies, and per-request control over redirects, timeouts, TLS verification and proxies
• Authentication — Basic, Bearer, API key and custom schemes
• WebSocket — ws:// and wss:// requests saved alongside HTTP ones, with a composer and a searchable message log
• gRPC — unary and streaming calls, with the schema from server reflection or imported .proto files, Send and End Streaming, and each call's status, metadata and trailers
• Server-sent events — a text/event-stream response shown event by event as it arrives
• Collections, environments, history and Markdown documentation
• OpenAPI 3.0, 3.1 and 3.2 import and export, in JSON or YAML
• Copy as cURL — turn any request into a command you can paste elsewhere

Windows 10 or 11, 64-bit. A release build produces two installers — an NSIS setup program and an MSI for deployment tooling. Both install the same single executable. A Microsoft Store listing is prepared but not published yet.

The app draws its interface with the Microsoft Edge WebView2 Runtime, which is part of Windows 11 and already present on most Windows 10 machines. If it is missing, Windows Update or Microsoft’s standalone installer adds it.

Linux, 64-bit (x86_64). A release build produces an RPM for Fedora, tested on Fedora 44. Install it with sudo dnf install ./ResponderHTTP-1.1.0-1.x86_64.rpm, which brings in WebKitGTK and GTK from Fedora’s own repositories. Those draw the window, the way WebView2 does on Windows, and they are the only system libraries the app uses: libcurl, TLS and SQLite are still compiled into the binary. An AppImage for other distributions and a Flatpak for any distribution are built and tested too, and a Flathub listing is planned. The Linux page lists the minimum distribution for each package and how to install it.

macOS is not supported today.

• Open the app — a blank request tab is already waiting
• Type https://httpbin.org/get in the URL bar
• Press Send

The response pane fills in: a status pill, how long it took, the size, and the body with syntax highlighting. The timing line underneath breaks the total into DNS, connect, TLS and time-to-first-byte, which is usually enough to tell a slow server from a slow network. Press Ctrl+S to keep the request in a collection.

Params are a table view of the URL’s query string, kept in step both ways: edit a row and the URL updates, edit the URL and the rows follow. Headers autocomplete the common names and their usual values.

• Raw — JSON, XML, HTML or plain text, with the content type you pick
• Form URL-encoded — a key-value table
• Multipart — text fields and file parts; a file part stores the path, and the file is read from disk as the request is sent, so a large upload never sits in memory

Authentication is Basic, Bearer token, API key (in a header or the query string), or a custom header. Anything the app treats as a secret is encrypted before it is saved.

The bar across the top shows the status code, the total time, the size and the timing breakdown. Three views: Pretty for formatted JSON and XML, Raw for exactly what arrived, and Headers.

• Hover the size for a breakdown: response headers and body, request headers and body. A gzipped response counts decoded — the size of what you are looking at
• Save response keeps it next to the request that produced it, as an example
• Send and download — the chevron beside Send — writes the body straight to a file, so a multi-gigabyte download costs nothing in memory

A response that arrives as Content-Type: text/event-stream is shown event by event while it is still arriving. There is nothing to switch on and Send stays one button — it is the response that differs, not the request.

• Events — one row per event, numbered, with its event name, id and a millisecond timestamp, newest first
• Raw — the stream exactly as it arrived, growing as it goes
• A Streaming badge, a running event count and a byte total while the stream is open

The request timeout stops applying once a response turns out to be a stream: a timeout is there to stop you waiting forever for a response, not to cut one off that is working. A request that never answers still times out. The viewer keeps the most recent 1 000 events, up to 32 MiB, and says how many earlier ones it dropped.

WebSocket requests live in the same collections as HTTP ones. Connect performs the handshake; the badge follows the connection state. Query parameters and handshake headers work as they do for HTTP, and the cookie jar is offered to the handshake unless you turn that off.

• The composer sends Text, JSON, XML, HTML or Binary — binary typed as Base64 or hexadecimal, whichever you prefer
• Beautify for JSON, XML and HTML; text that does not parse is left exactly as you typed it, with the reason shown
• A message log, newest first, with millisecond timestamps, expandable rows, a direction filter and a search box
• Per-request settings: handshake timeout, largest message to accept, and automatic reconnect for an unexpected drop

gRPC requests live in the same collections as HTTP and WebSocket ones. Enter the server as host:port and set the lock: on for TLS, off for plain-text HTTP/2 (h2c). Pasting a grpcs:// or grpc:// address sets the lock for you. Then pick a method from the list, grouped by service, and Invoke.

• The schema — ask the server for it by reflection, or import .proto files together with the folders their imports live in. An imported schema is saved to a schema library, so a saved request keeps working after the files move
• All four kinds of call — unary, server streaming, client streaming and bidirectional. Messages are written as JSON; Use Example Message fills in every field of the chosen method, and 64-bit numbers come back exactly as the server sent them
• Streaming — Invoke opens the call, Send adds one message at a time, End Streaming closes your side, and Cancel stops the call. Every message lands in a log with the same filter and search as WebSocket
• The response — the message, the response metadata and trailers, and the status as its code and name (0 OK, 5 NOT_FOUND), with the time and size. A status other than OK is a result, shown like any other response
• Metadata and authorization work as headers do for HTTP, with {{variables}} and secret variables. Copy as grpcurl gives you the same call as a command
• Per-request settings — connect timeout, deadline, the largest response message to accept, and a proxy

Save a request with Ctrl+S. Collections hold folders, folders hold requests, and the tree is yours to arrange — rename, duplicate, move, delete, all from the right-click menu.

• Environments — write {{base_url}} anywhere in a request and the active environment’s value is substituted when you send. Requests are saved with the placeholders intact, so the same request works against staging and production
• Secret variables — encrypted with a key held in the system’s credential store (Windows Credential Manager, or the desktop keyring on Linux), never in history, examples or the log
• History — every request you sent, with its status and duration, ready to re-send
• Documentation — Markdown notes on any collection, folder or request, with Edit, Preview and Split views
• Cookies — a jar that follows RFC 6265, with a manager for inspecting and clearing it

Import a 3.0, 3.1 or 3.2 document, in JSON or YAML, as a new collection. Nothing is written until you confirm: the dialog shows how many requests and saved responses it found, lets you choose how they are grouped into folders, and offers to create an environment from the document’s servers. Descriptions come in as documentation.

Export a collection back out, choosing the version and JSON or YAML; request and response shapes are inferred from the examples you saved. WebSocket and gRPC requests cannot be exported — the OpenAPI specification has no way to describe them, and the dialog says how many it is leaving out.

Every request carries its own settings, saved with it.

Closing the window hides the app to the notification area rather than quitting it, so requests in flight and open WebSocket connections survive. The first few closes say so in a toast with a "Don’t show this again" button. The tray icon’s menu has Show and Quit.

On Linux the window hides to the tray only when the desktop shows tray icons, as KDE Plasma does, or GNOME with an AppIndicator extension. There is no toast. Where there is no tray, as on a stock Fedora Workstation, closing the window quits, and first asks if a tab has unsaved changes or a request, stream, WebSocket connection or gRPC call is still running.

One SQLite database plus a log folder, under your user profile. On Windows:

%APPDATA%\io.github.zoran-php.responderhttp\
    responderhttp.sqlite3      collections, environments, gRPC schemas, history, cookies, settings
    logs\                      rotating log files

On Linux, installed from the RPM:

~/.local/share/io.github.zoran-php.responderhttp/
    responderhttp.sqlite3      the same database
    logs/                      rotating log files

Installed from the Microsoft Store, the Windows files live under %LOCALAPPDATA%\Packages\<package>\LocalCache\, which Windows removes when the app is uninstalled.

• Back up by copying the database while the app is closed — but note that secrets in it are encrypted with a key in Windows Credential Manager or your Linux desktop keyring, so the database alone will not carry them to another machine
• Start over by closing the app and deleting the database; it is recreated empty on the next start
• The log records what happened, never what was in it: bodies, auth headers, tokens, cookies, WebSocket and gRPC messages, gRPC metadata and stream events are all kept out

• "The database was created by a newer version." A dialog says so at startup and the app stops rather than touching the file. Install the newer version, or move the database aside to start fresh
• A request fails with a TLS error. Check the clock, the certificate chain and any corporate proxy first. Turning off Verify TLS for that one request will tell you whether that is the cause — and it should go back on
• A gRPC call fails with “The TLS handshake failed” or “did not answer plain-text HTTP/2”. The lock does not match the server: turn it off for a plain-text (h2c) port, on for a TLS one
• Everything times out behind a corporate network. Set the proxy in the request’s Settings tab
• A stream stops after 30 seconds. It should not: the timeout is lifted once a response identifies itself as text/event-stream. If it is being cut off, the response is probably not sending that content type
• Secrets ask to be re-entered. The data key in Credential Manager could not be read — usually a different Windows account, or a restored profile. The stored values cannot be recovered
• Secrets cannot be saved on Linux. The app keeps its data key in the desktop keyring — GNOME Keyring or KWallet — and never falls back to plain text. With no keyring running, secrets refuse to save for that session, and a locked keyring asks to be unlocked. Check that the keyring runs, and unlock it when asked
• The window does not appear. The app may be in the notification area — click its tray icon, or use Show from the icon’s menu. Starting the app again also brings the running window back