Skip to content
WePROXA
Blog
Windows

WePROXA 3.0.0 now supports Windows and macOS. Windows installation is available from the Microsoft Store.

MCP Integration

Overview

Section titled “Overview”

WePROXA runs a local Streamable HTTP MCP server that lets compatible AI tools inspect captured traffic and operate WePROXA’s debugging features.

The server:

  • binds to the loopback interface, so it is available only on your computer;
  • uses a dynamic endpoint such as http://127.0.0.1:8765/mcp;
  • requires a bearer token on every connection;
  • exposes captured-traffic, saved-request, capture-session, request-replay, Workspace, Scenario, bundle, proxy, rule-management, paused-breakpoint, containment, certificate, SSL-host, and tool-state capabilities.

MCP tools can both read data and change WePROXA state. Review an AI client’s proposed tool calls before approving actions that start or stop the proxy, activate a Workspace or Scenario, or change rules.

Enable the MCP server

Section titled “Enable the MCP server”
  1. Open Settings in WePROXA.
  2. Select MCP Server.
  3. Keep Hide sensitive data enabled unless you have a specific reason to expose unredacted captured values.
  4. Choose Start.
  5. Copy the exact Endpoint URL shown in WePROXA.

WePROXA MCP Server settings

Connect an AI tool

Section titled “Connect an AI tool”

Choose your client, scope, and endpoint below. The generator creates the client’s own configuration format rather than applying one JSON shape everywhere.

Private, local configuration

Build your client configuration

Generation happens in this browser tab. WePROXA’s token is never requested, read, stored, or sent by this page.

Runs locally

Port 8765 is preferred, not guaranteed. Copy the exact endpoint shown in WePROXA—if that port is busy, the server uses another local port.

AI client
Configuration scope

Selected client

VS Code / GitHub Copilot

VS Code mcp.json

GitHub Copilot Chat and Agent mode use VS Code’s native MCP support. “VS Code” on this page does not mean the Codex or Claude extensions.

Store or enter it
Run “MCP: Open User Configuration” to edit your profile’s mcp.json.
Manual fallback
Run “MCP: Add Server” or open the selected mcp.json, then merge the generated weproxa entry without removing your other servers.
Verify
Run “MCP: List Servers”, open WePROXA, and inspect its discovered tools. You can also use “Configure Tools” in Chat.
Remove or disable
Disable WePROXA from “MCP: List Servers”, or remove its entry from the selected mcp.json.
Client-specific troubleshooting
Choose “Show Output” or “Restart Server”. If tools are stale, run “MCP: Reset Cached Tools”.

Generated format

VS Code mcp.json

Token placeholder only 
{
  "servers": {
    "weproxa": {
      "type": "http",
      "url": "http://127.0.0.1:8765/mcp",
      "headers": {
        "Authorization": "Bearer <WEPROXA_AUTH_TOKEN>"
      }
    }
  }
}
Open WePROXA to connect

Copy the auth token from WePROXA

  1. Open Settings → MCP Server in WePROXA.
  2. Choose Copy Auth Token. The documentation page never receives it.
  3. Replace <WEPROXA_AUTH_TOKEN> in the copied configuration, then save or run it locally.
The app handoff sends only the selected client and scope. It never includes the endpoint, token, configuration, or a file path.

The generated formats follow each client’s current MCP contract: VS Code, Cursor, Codex, Claude Code, and JetBrains AI Assistant.

Generate the configuration inside WePROXA

Section titled “Generate the configuration inside WePROXA”

Settings → MCP Server → AI Connections does the same job without leaving the app. It builds the configuration from the live endpoint and the token currently in use, so there is nothing to paste in by hand and nothing to keep in sync.

  1. Start the MCP server.
  2. Open Settings → MCP Server and go to AI Connections.
  3. Select your client and a User or Workspace configuration scope.
  4. Choose View configuration to review it, then Copy configuration. Use Copy token when a client only needs the bearer token.
  5. Paste it into your client. Open client instructions explains where that file lives and how to remove the entry later.

Each client shows its own status:

  • Not configured — nothing has been copied for the selected scope yet.
  • Setup copied — you copied a configuration that still matches the running server.
  • Connected — the client completed a real MCP handshake. WePROXA shows its reported version and the last connection time.
  • Needs attention — the copied setup is stale because the server stopped, its endpoint changed, or the token was regenerated. Start the server and copy a fresh configuration.

Only Connected reflects a verified connection; the other states describe your setup progress. If a client that WePROXA does not recognize completes a handshake, the panel reports it generically rather than retaining the arbitrary name it sent.

The Open WePROXA to connect button in the generator above hands the selected client and scope to this panel through a weproxa:// deep link. The link only preselects those two values — it never starts the server and never carries credentials.

Verify the connection

Section titled “Verify the connection”

Use the client-specific verification guidance in the selector, then run this harmless test:

Ask WePROXA for the current proxy status. Do not start, stop, or modify anything.

Expected client checks:

  • VS Code / GitHub Copilot: run MCP: List Servers, select WePROXA, and inspect its tools.
  • Cursor: open MCP settings and confirm WePROXA’s tools are enabled.
  • Codex CLI or VS Code extension: run codex mcp list or use /mcp.
  • Claude Code terminal or VS Code extension: run claude mcp list or use /mcp.
  • JetBrains AI Assistant: check the connection status and open the available-tools list.
  • Other clients: use the client’s MCP server-status and tool-discovery view.

A configured entry is not proof of a working connection. Confirm that the server is connected, authenticated, and advertising weproxa_proxy_status.

Example debugging workflows

Section titled “Example debugging workflows”

Read-only prompts

Section titled “Read-only prompts”

These prompts inspect current state and should not modify WePROXA:

Inspect recent failed requests

List the 20 most recent captured requests with an HTTP status of 400 or higher.
Summarize the failing hosts, paths, methods, and status codes. Do not modify WePROXA.

Diagnose an API response

Inspect the captured request and response for request ID <REQUEST_ID>.
Explain the most likely cause of the API failure using its status, headers, and bounded body.
Do not create rules or change proxy state.

Check the active Workspace

List WePROXA Workspaces and tell me which Workspace is active.
Then list that Workspace's active Scenario and effective tool states. Do not change anything.

Prompts that change state

Section titled “Prompts that change state”

The following prompts create or activate debugging configuration. Review the proposed values and approve the tool call only when they are correct.

Create a Map Local rule

First summarize the active Workspace and Scenario. Then create an enabled Map Local rule named
"Mock profile" for GET requests matching **/api/profile, using the local file
/absolute/path/to/profile.json. This changes WePROXA state; show the exact rule before creating it.

Add Network Conditioning

In the active Workspace and Scenario, create an enabled Network Conditioning rule named
"Slow catalog" for **/api/catalog with a 1200 ms response delay and no request delay.
Show the proposed rule and ask for confirmation before creating it.

Create or activate a Scenario

In the active Workspace, create a Scenario named "Checkout timeout" with acceptance criteria that
the checkout UI shows a retry action after a delayed response. Preview activation first, summarize
the effective-rule and tool-state changes, and ask for confirmation before activating it.

Security

Section titled “Security”
  • Treat the bearer token like a password. The documentation generator never asks for it and never connects to localhost.
  • Configuration generation runs entirely in the browser. Nothing is submitted to WePROXA’s website or another server.
  • Generated examples contain only <WEPROXA_AUTH_TOKEN>. Replace that placeholder locally after copying the token from WePROXA.
  • The app handoff URL contains only a controlled client and scope. It never contains an endpoint, token, configuration, hostname, port, or file path.
  • Client configuration files may store the Authorization header locally. Restrict file access and never commit a real token to version control.
  • Hide sensitive data redacts likely credentials and payment-card values in traffic returned through MCP. Binary bodies that cannot be inspected safely are omitted.
  • Request and response bodies returned by detail tools are bounded. Request listings do not include response bodies.
  • Regenerating the token immediately invalidates the previous token. Update every configured client after regeneration.
  • The server listens on loopback only. A client running on another computer, VM, container, or remote development host cannot use the host machine’s 127.0.0.1 endpoint directly.

Troubleshooting

Section titled “Troubleshooting”

The endpoint refuses the connection

Confirm the MCP server is running and copy its current endpoint again. Port 8765 may have been busy, causing WePROXA to choose another port.

The client reports Unauthorized or HTTP 401

Copy the current auth token from Settings → MCP Server and replace the placeholder or stale header locally. If the token was regenerated, every old client configuration is invalid.

The server connects but tools are missing

Restart or refresh the server from the client. VS Code can run MCP: Reset Cached Tools. Also confirm you connected to /mcp using Streamable HTTP rather than a legacy /sse transport.

The generated endpoint is rejected

Only loopback http:// URLs with an explicit port and the exact /mcp path are accepted. Credentials, query parameters, and fragments do not belong in the endpoint.

The app handoff does not open

Open WePROXA manually and go to Settings → MCP Server. Clicking a handoff never means the connection was installed; verify it from the client afterward.

A project-scoped client does not load the server

Trust the project where required, confirm the configuration is in that client’s exact workspace location, and check that a higher-precedence user or local entry is not shadowing it.

A remote or containerized client cannot connect

127.0.0.1 refers to the client’s own environment. Run the MCP client on the same host as WePROXA. Do not expose the local MCP server through a public tunnel.

Available tools reference

Section titled “Available tools reference”

Conventions

Section titled “Conventions”
  • Tool names start with weproxa_ and parameters use camelCase.
  • Responses include a success or state result; validation failures include an error message.
  • urlPattern values use WePROXA glob syntax such as **/api/*.json.
  • An optional method limits a rule to one HTTP method; omitting it matches all methods.
  • Add operations return a UUID that can be passed to the corresponding update or remove operation.
  • Rule limits, Scenario limits, validation, active-Workspace ownership, and active-Scenario assignment are enforced by WePROXA.
  • Every listRules tool accepts an optional workspaceId to inspect a Workspace without activating it. Omit it to use the active Workspace.
  • Listings are returned in precedence order: the rule listed first is the rule that will answer.
  • priority, externalKey, and tags are deliberately not part of the update tools. Those tools replace the whole rule, so they would wipe those fields on every unrelated edit. Use weproxa_rules_setPriority and weproxa_rules_annotate instead.

Captured traffic

Section titled “Captured traffic”

weproxa_requests_list

Section titled “weproxa_requests_list”

List captured HTTP requests using advanced query filters, bounded pagination, and newest/oldest ordering. Response bodies are not included.

weproxa_requests_getRequest

Section titled “weproxa_requests_getRequest”

Get one captured request by ID, including headers and a bounded body. Sensitive values are redacted when MCP privacy protection is enabled.

weproxa_requests_getResponse

Section titled “weproxa_requests_getResponse”

Get the captured response for a request ID, including headers and a bounded body. Sensitive values are redacted when MCP privacy protection is enabled.

weproxa_requests_clear

Section titled “weproxa_requests_clear”

Delete every captured request from the traffic log and return how many were cleared. Call it at the start of an exploration pass so captured traffic reflects only the current run. When runs need to be compared rather than discarded, open a capture session instead.

weproxa_requests_listUnmatched

Section titled “weproxa_requests_listUnmatched”

List captured requests that matched no Map Local rule, deduplicated by method and URL pattern. This is the work queue for fixture generation: each entry names an endpoint the app asked for that you have not mocked, with a urlPattern glob you can pass straight to weproxa_mapLocal_addRule, an exampleRequestId, and the statuses observed.

CONNECT entries are hidden by default. Pass includeTunnels: true to surface hosts WePROXA could not decrypt — each names a host to add with weproxa_ssl_addHost, not an endpoint to mock. A tunnel that stays encrypted can never match a rule.

weproxa_requests_replay

Section titled “weproxa_requests_replay”

Resend a request and return the response — status, headers, a bounded body, and the round-trip duration.

Either start from a captured request with requestId and edit it (method, url, setHeaders / removeHeaders, body), or state one outright with method and url. Anything else is rejected rather than guessed at: a request sent to the wrong place cannot be taken back.

Headers are a patch, so you never restate the ones you are not changing and never echo back a redacted value. An unmodified captured body is resent as the bytes that crossed the wire; replacing the body drops the Content-Encoding and Transfer-Encoding that described the bytes it replaced.

The replay runs through the same executor as the Repeat editor, so it is logged as a new request (its ID is returned), timed, attributed to the original’s client, and marked with the Repeat tool wherever it came from. A failure that got as far as dialing still returns the ID it was logged under — a failed replay is a record in the traffic log, and the one exchange you most need to read back in full.

Saved requests

Section titled “Saved requests”

weproxa_savedRequests_list

Section titled “weproxa_savedRequests_list”

List saved snapshots newest first with bounded pagination. Bodies are omitted.

weproxa_savedRequests_save

Section titled “weproxa_savedRequests_save”

Save a captured HTTPS request and its current response as an immutable snapshot. SSL interception must be enabled for the request. Repeating the call for the same captured request is idempotent.

weproxa_savedRequests_getRequest

Section titled “weproxa_savedRequests_getRequest”

Get one saved request by saved-request ID, including headers and a bounded body.

weproxa_savedRequests_getResponse

Section titled “weproxa_savedRequests_getResponse”

Get the response stored with a saved request, including headers, a bounded body, tool markers, and the Map Local rule that answered it.

weproxa_savedRequests_remove

Section titled “weproxa_savedRequests_remove”

Permanently remove one saved snapshot by its saved-request ID.

Capture sessions

Section titled “Capture sessions”

A capture session tags every request observed while it is open, so several exploration runs can share one traffic log and still be told apart. Sessions live in memory for the lifetime of the app, like the traffic they describe.

weproxa_session_start

Section titled “weproxa_session_start”

Open a named session and tag subsequent captures with its ID. Any session still open is closed first, and reported. Returns sessionId.

weproxa_session_end

Section titled “weproxa_session_end”

Close a session and return its summary. Defaults to the open session.

weproxa_session_summary

Section titled “weproxa_session_summary”

Return a session’s summary without closing it. Defaults to the open session.

Both summaries report the request count, the duration, an overlapping per-tool breakdown of what handled each response, and answeredByOriginCount — how many requests the upstream origin actually answered. That last number is the false-pass signal: in a run that is supposed to be fully mocked, it should be zero. Pass-Through denials are counted under passthrough.

Workspaces

Section titled “Workspaces”

weproxa_workspaces_list

Section titled “weproxa_workspaces_list”

List all Workspaces and the active Workspace ID.

weproxa_workspaces_create

Section titled “weproxa_workspaces_create”

Create a Workspace and make it active.

weproxa_workspaces_rename

Section titled “weproxa_workspaces_rename”

Rename an existing Workspace.

weproxa_workspaces_delete

Section titled “weproxa_workspaces_delete”

Delete a Workspace and its owned rules. The last Workspace cannot be deleted.

weproxa_workspaces_activate

Section titled “weproxa_workspaces_activate”

Activate a Workspace and atomically replace the proxy’s live rules with its active Scenario.

Scenarios

Section titled “Scenarios”

weproxa_scenarios_list

Section titled “weproxa_scenarios_list”

List a Workspace’s Scenarios, active Scenario ID, Shared Rule references, and per-Scenario tool states.

weproxa_scenarios_create

Section titled “weproxa_scenarios_create”

Create an empty Scenario without activating it. It starts with all five rule tools enabled unless initialToolStates says otherwise, so its rules answer traffic as soon as it is activated. Containment, SSL prerequisites, and tags can be declared here instead of through their own tools; an invalid declaration creates nothing rather than a half-configured Scenario.

weproxa_scenarios_update

Section titled “weproxa_scenarios_update”

Update a Scenario’s name, acceptance criteria, expected outcome, and ticket URL.

weproxa_scenarios_duplicate

Section titled “weproxa_scenarios_duplicate”

Duplicate a Scenario’s metadata, rule references, and tool states under a unique name.

weproxa_scenarios_delete

Section titled “weproxa_scenarios_delete”

Delete a Scenario. The last Scenario in a Workspace cannot be deleted.

weproxa_scenarios_previewActivation

Section titled “weproxa_scenarios_previewActivation”

Preview effective-rule counts and tool-state changes before activation. Also reports provably shadowed rules, the containment it would install, declared SSL hosts this machine does not decrypt, and warnings — rules sitting under a tool the Scenario switches off would never fire.

weproxa_scenarios_activate

Section titled “weproxa_scenarios_activate”

Activate a Scenario in the active Workspace and atomically apply its effective rules, tool states, and Pass-Through containment.

Returns the containment now in force, any declared SSL host this machine does not decrypt, and warnings about rules that cannot fire under the Scenario’s own tool switches. Each of those is a rule that will silently never match, which is what makes a run green for the wrong reason.

Re-activating the live Scenario re-asserts its containment, which is how you return to a sealed proxy after a manual override.

weproxa_scenarios_setPassthrough

Section titled “weproxa_scenarios_setPassthrough”

Declare the Pass-Through containment a Scenario installs when activated, so a sealed environment travels with the Scenario and its bundle instead of being set by hand on every machine. It takes effect immediately if the Scenario is live.

Omit passthrough to clear the declaration. A Scenario that declares nothing reverts containment a previous Scenario installed but leaves a manually set policy alone. Containment is never restored at launch — WePROXA always starts in allow.

weproxa_scenarios_setSslPrerequisites

Section titled “weproxa_scenarios_setSslPrerequisites”

Declare the hosts a Scenario needs WePROXA to decrypt for its HTTPS rules to match. The list travels in the bundle, and import and activation report which of them this machine does not intercept. Nothing is applied automatically, because SSL host configuration is global rather than Workspace-scoped.

weproxa_scenarios_setTags

Section titled “weproxa_scenarios_setTags”

Replace a Scenario’s free-form key/value labels. They are sorted on write, so a bundle exported before and after an unrelated change still diffs cleanly.

Scenario bundles

Section titled “Scenario bundles”

A bundle is always a file path, never a tool payload: it embeds every referenced rule and Map Local fixture and can reach 128 MiB, and its purpose is to be committed next to the code it mocks. See Bundles as a committed artifact.

weproxa_scenarios_export

Section titled “weproxa_scenarios_export”

Write a Scenario to a bundle file at an absolute path. The parent directory must exist. Returns the path, the exact file SHA-256, a portable content SHA-256 that normalizes generated rule IDs, timestamps, and embedded-file source paths, the content-normalization version that must be stored with that digest, its size, and warnings worth fixing before the file is committed. Requires WePROXA Pro.

weproxa_scenarios_importPreview

Section titled “weproxa_scenarios_importPreview”

Dry-run an import: the rules it would create, the fixtures it would write, whether the Scenario name collides, and — for unlicensed Workspaces — the exact per-tool limit arithmetic (existing + incoming vs allowed). Nothing is written. Set sharedRules to omit to see what dropping the source’s Shared Rules would leave behind.

weproxa_scenarios_import

Section titled “weproxa_scenarios_import”

Import a bundle file as a new Scenario with fresh rule IDs. The Scenario is created but not activated. Import is available to unlicensed Workspaces, subject to the per-tool rule limits — run weproxa_scenarios_importPreview first to see them. sharedRules: "omit" imports only what the Scenario references directly and reports every rule it dropped.

Cross-tool rule management

Section titled “Cross-tool rule management”

weproxa_rules_list

Section titled “weproxa_rules_list”

List Map Local, Breakpoint, Block List, Network Conditioning, and Scripting rules in one call. Filters apply across every tool, results identify the inspected Workspace, and every rule is tagged with its owning tool. Rules report their hit counts, so a fixture with zero hits after a run is dead or shadowed.

weproxa_rules_createBatch

Section titled “weproxa_rules_createBatch”

Create, refresh, or explicitly prune with up to 200 operations across all five rule tools in one atomic call. The whole batch is validated first and committed together — one disk write and one matcher rebuild per affected tool instead of one per rule — so a failure never leaves a half-built Scenario, which is itself a false green.

Entries use the same shape as the single-rule add tools, tagged with tool, so there is no second schema to learn.

  • An entry whose externalKey already belongs to a rule in the target Workspace is content-compared: changed content refreshes that rule in place, preserving its ID, creation time, priority, and Scenario membership; content identical to the stored rule keeps its updatedAt and hit counter and is reported as unchanged. A repeated authoring pass is therefore idempotent and does not reshuffle the matcher.
  • Pass stale keys in pruneExternalKeys to delete their rules and Scenario references in the same transaction. Missing keys are successful no-ops.
  • Submission order decides precedence among newly created rules sharing the neutral priority band, so list narrow fixtures before catch-alls.
  • Pass workspaceId to author into a Workspace without activating it; omit it to use the active one.

weproxa_rules_setPriority

Section titled “weproxa_rules_setPriority”

Set a rule’s explicit precedence so it wins or loses against overlapping rules. Higher priority wins; rules sharing a band still resolve oldest-first, which is how every rule behaves until a priority is set. Omit priority to clear it.

weproxa_rules_annotate

Section titled “weproxa_rules_annotate”

Set or clear a rule’s externalKey and free-form tags. Omitted fields are left alone; an empty string clears the key and an empty object clears the tags. External keys are unique across the Workspace, not per tool.

weproxa_rules_assign

Section titled “weproxa_rules_assign”

Assign an existing rule to a Scenario or to the Workspace’s Shared set, or unassign it. This is how one rule answers traffic in several Scenarios — without it, a baseline fixture has to be duplicated per Scenario. Pass assigned: false to remove the reference; removing the last one leaves the rule in the Rule Library, stored but matching nothing.

Proxy lifecycle

Section titled “Proxy lifecycle”

weproxa_proxy_start

Section titled “weproxa_proxy_start”

Start the HTTP/HTTPS proxy with an optional port and system-proxy configuration.

weproxa_proxy_stop

Section titled “weproxa_proxy_stop”

Stop the proxy.

weproxa_proxy_status

Section titled “weproxa_proxy_status”

Read the current running state, port, and LAN-access state without changing anything.

Map Local

Section titled “Map Local”

weproxa_mapLocal_addRule

Section titled “weproxa_mapLocal_addRule”

Add a rule that serves an inline body, a local file, or a remote HTTP(S) asset for matching requests.

Set sourceType: "inline" and pass body to author a fixture in one call, with no file to write or keep in sync. statusCode and responseHeaders override whatever the source returned, whichever source that is, and match narrows the rule to some of the requests its URL pattern accepts:

{
  "name": "Orders — page 2",
  "urlPattern": "**/api/orders",
  "method": "GET",
  "sourceType": "inline",
  "statusCode": 200,
  "responseHeaders": [{ "name": "content-type", "value": "application/json" }],
  "match": { "queryParams": [{ "name": "page", "op": "equals", "value": "2" }] },
  "body": "{\"orders\":[],\"page\":2}"
}

match also reads request headers, a request-body substring (bodyContains), and JSON fields (bodyJsonPath, such as user.email). Every condition takes op: "equals" | "exists" | "absent", and all of them must hold. See Request Match Conditions.

weproxa_mapLocal_updateRule

Section titled “weproxa_mapLocal_updateRule”

Update an existing Map Local rule.

weproxa_mapLocal_removeRule

Section titled “weproxa_mapLocal_removeRule”

Remove a Map Local rule by ID.

weproxa_mapLocal_listRules

Section titled “weproxa_mapLocal_listRules”

List Map Local rules.

Breakpoints

Section titled “Breakpoints”

weproxa_breakpoints_addRule

Section titled “weproxa_breakpoints_addRule”

Add a rule that pauses matching requests, responses, or both for inspection.

weproxa_breakpoints_updateRule

Section titled “weproxa_breakpoints_updateRule”

Update an existing Breakpoint rule.

weproxa_breakpoints_removeRule

Section titled “weproxa_breakpoints_removeRule”

Remove a Breakpoint rule by ID.

weproxa_breakpoints_listRules

Section titled “weproxa_breakpoints_listRules”

List Breakpoint rules.

Paused breakpoints

Section titled “Paused breakpoints”

A Breakpoint rule only arms the trap. These tools act on requests it is actually holding, which is what makes the intercept-and-modify loop reachable from an AI client rather than only from the breakpoint editor window.

weproxa_breakpoints_listPending

Section titled “weproxa_breakpoints_listPending”

List the requests and responses currently held paused, oldest first. This surface is poll-shaped on purpose: a request can sit paused for up to five minutes, which is the wrong thing to hold an HTTP tool call open for.

Poll it after arming a rule — a paused request blocks its client until something releases it. Each entry reports the deadline after which WePROXA releases it as aborted, and whether the Breakpoints tool is even enabled.

weproxa_breakpoints_resolve

Section titled “weproxa_breakpoints_resolve”

Release a paused request or response, optionally rewriting it first.

Headers are a patch (setHeaders / removeHeaders) applied to the paused message, so you never restate the ones you are not changing and never echo back a [REDACTED] value that would then go out on the wire. A request hit takes url; a response hit takes statusCode; both take body.

Naming a field the paused phase cannot apply — url on a response, statusCode on a request, a status outside 100–599 — is rejected and leaves the request paused, rather than being silently dropped. Replacing the body drops the Content-Encoding and Transfer-Encoding that described the bytes it replaced; WePROXA restates Content-Length.

weproxa_breakpoints_cancel

Section titled “weproxa_breakpoints_cancel”

Abort a paused request or response. Its client receives a 499, exactly as it would from the Abort button in the breakpoint editor. Use it to test how a client handles a dropped call.

Block List

Section titled “Block List”

weproxa_blockList_addRule

Section titled “weproxa_blockList_addRule”

Add a rule that blocks matching HTTP requests.

weproxa_blockList_updateRule

Section titled “weproxa_blockList_updateRule”

Update an existing Block List rule.

weproxa_blockList_removeRule

Section titled “weproxa_blockList_removeRule”

Remove a Block List rule by ID.

weproxa_blockList_listRules

Section titled “weproxa_blockList_listRules”

List Block List rules.

Network Conditioning

Section titled “Network Conditioning”

Request and response delays are limited to 300,000 ms (five minutes) per rule.

weproxa_networkConditioning_addRule

Section titled “weproxa_networkConditioning_addRule”

Add request and/or response delay to matching traffic.

weproxa_networkConditioning_updateRule

Section titled “weproxa_networkConditioning_updateRule”

Update an existing Network Conditioning rule.

weproxa_networkConditioning_removeRule

Section titled “weproxa_networkConditioning_removeRule”

Remove a Network Conditioning rule by ID.

weproxa_networkConditioning_listRules

Section titled “weproxa_networkConditioning_listRules”

List Network Conditioning rules.

Scripting

Section titled “Scripting”

weproxa_scripting_addRule

Section titled “weproxa_scripting_addRule”

Add a Rhai script that can mutate matching requests and/or responses.

weproxa_scripting_updateRule

Section titled “weproxa_scripting_updateRule”

Update an existing Scripting rule.

weproxa_scripting_removeRule

Section titled “weproxa_scripting_removeRule”

Remove a Scripting rule by ID.

weproxa_scripting_listRules

Section titled “weproxa_scripting_listRules”

List Scripting rules.

SSL Hosts

Section titled “SSL Hosts”

weproxa_ssl_addHost

Section titled “weproxa_ssl_addHost”

Add a host pattern for HTTPS interception. The WePROXA CA must already be trusted.

weproxa_ssl_updateHost

Section titled “weproxa_ssl_updateHost”

Update an existing SSL host.

weproxa_ssl_removeHost

Section titled “weproxa_ssl_removeHost”

Remove an SSL host by ID.

weproxa_ssl_listHosts

Section titled “weproxa_ssl_listHosts”

List SSL hosts configured for interception.

Certificates

Section titled “Certificates”

weproxa_certs_getCaInfo

Section titled “weproxa_certs_getCaInfo”

Return the local CA certificate’s file path, SHA-256 fingerprint, expiry, and whether the macOS keychain currently trusts it. An untrusted or expired CA explains every decryption failure, so check this before adding hosts or installing anywhere.

weproxa_certs_installToIosSimulator

Section titled “weproxa_certs_installToIosSimulator”

Install the WePROXA CA into a booted iOS Simulator’s trust store. Accepts an optional udid; it defaults to the booted simulator and requires one when several are booted. See iOS Simulator.

Pass-Through containment

Section titled “Pass-Through containment”

Governs what the proxy does with a request no Map Local rule answered. See Pass-Through Containment for the full behavior.

weproxa_passthrough_setMode

Section titled “weproxa_passthrough_setMode”

Set the mode: allow forwards upstream (the default), denyUnmatched refuses any request no rule answered without contacting the origin, and denyAll blocks every request regardless of matching. Accepts an optional allowHosts list of hosts that must stay reachable, which replaces the previous list.

Use denyUnmatched during exploration so a missing mock cannot reach production. The mode resets to allow when WePROXA restarts.

weproxa_passthrough_getMode

Section titled “weproxa_passthrough_getMode”

Return the current mode, its source (default, manual, or scenario), and any host allow-list. Call it before a run rather than assuming containment survived — it never survives a restart.

Tool enable/disable

Section titled “Tool enable/disable”

weproxa_tools_getEnabled

Section titled “weproxa_tools_getEnabled”

Read the enabled state of Map Local, Breakpoints, Block List, Network Conditioning, and Scripting.

weproxa_tools_setEnabled

Section titled “weproxa_tools_setEnabled”

Enable or disable one debugging tool. A tool switch belongs to a Scenario, not to the app: pass workspaceId and scenarioId to configure a Scenario you have not activated, or omit both to flip the live Scenario’s switch.