Privacy and network access

Fetchpier is local-first: it has no account, team server, telemetry, analytics, usage reporting, or background synchronization. Workspaces remain ordinary folders you control.

Network connections

Every connection originates from an action or configuration you control:

• HTTP requests you send, including redirects and proxy traffic implied by those requests;
• schema imports you explicitly start from an HTTP or HTTPS URL;
• a product-catalogue update check, which runs only when you click Check now in the updates dialog.

The interface does not load remote fonts, scripts, images, or web pages. Licence text is read from the copy distributed with the application. With the machine offline, workspace editing, history, environment management, and every other local feature continue to work; only operations that actually require a remote endpoint cannot complete.

This boundary is enforced by build-time audits, end-to-end tests, the renderer Content Security Policy, and navigation guards. The renderer cannot silently introduce a new remote dependency.

Data ownership and synchronization

Fetchpier does not upload workspace data. Requests, environments, settings, certificates, cookies, and history are files in the workspace; personal app state remains in the local user-data folder. Use Git, a file share, or your own synchronization system when you want to collaborate.

Review a workspace from an unfamiliar source before running it. Pre-request and post-response scripts execute in a deliberately small synchronous sandbox, but the sandbox protects against accidental API exposure rather than hostile code. Treat an untrusted .http file like an untrusted shell script and use an external isolation boundary, such as a container, when appropriate.

Deliberate boundaries

The current product intentionally does not provide:

• a Fetchpier cloud or team synchronization server;
• plugins beyond the documented fp.* scripting API;
• request mocks or fixtures;
• streaming responses, Server-Sent Events, or WebSockets;
• asynchronous scripts, promises, timers, filesystem access, or network access from scripts;
• operating-system trust-store integration;
• a GraphQL-specific runtime editor;
• restart recovery for unsaved untitled requests or unsaved edits;
• secret recovery, key escrow, or per-user encryption recipients.

GraphQL schemas can still be imported, but generated operations run as ordinary HTTP requests. Custom CAs must be imported explicitly. Saved, file-backed tabs are restored; unsaved work is protected by close prompts but is not persisted as a draft across restarts.

These are compatibility and security boundaries, not undocumented features. Design automation and team workflows around them rather than assuming cloud state or a browser-like runtime.