What Scripting is for
Problems, Investigate, and Compare cover the questions Hollowport anticipated. Scripting is for the ones it didn't — a JavaScript console that runs against your already-captured traffic, so you can search, filter, and summarize it however the moment actually calls for.
Opening it
Two entry points: More → Scripts opens the full Script Library — your saved scripts, the starter templates, Environments, and Shared State. Or tap Run Script… from any captured request's detail view to open the editor scoped to that flow specifically, with the rest of the current capture available too.
The Hollowport namespace
Every script runs against a single global object, Hollowport, built fresh for that run — never a live handle into the app itself. The parts you'll use most:
- Hollowport.flows.current — the flow you opened the script from, if any.
- Hollowport.flows.all(), .filter(), .byHost(), .failed(), .slow(ms), and similar — query the rest of the visible capture.
- Each flow exposes method, host, path, status, headers, body (as text or parsed JSON), timing breakdown, and — where relevant — gRPC and GraphQL fields.
- Hollowport.state — a small on-device key/value store that persists between runs, for scripts that build on a previous result.
- console.log() — printed output, shown after the script finishes.
Starter templates
29 ready-to-run scripts, grouped by what they're for — finding failed, slow, or repeated requests; security checks like exposed JWTs or API keys; GraphQL-specific queries; performance breakdowns by host. Tap one to duplicate it into your own library and adapt it, rather than starting from a blank editor.
require() and modules
Pull in a bundled helper with require("std/crypto") (also available as std/encoding, std/jwt, std/uuid, std/diff), or mark one of your own saved scripts as a module and require() it by name from another — the usual module.exports pattern, so shared logic doesn't get copy-pasted between scripts.
What a script can't do
No network access — no fetch, no sockets. No filesystem access. No way to modify live traffic; the request/response data a script sees is a snapshot, not a hook into the live path. This isn't just a stated rule — it's enforced by what the runtime actually exposes, and covered by its own test suite that asserts each of these is unavailable.
Limits worth knowing
A script gets 5 seconds by default before Hollowport reports it as timed out; console output and state values are size-capped so one runaway script can't fill up storage. None of this needs configuring up front — it only matters if a script is doing something unusually large.