Choose an integration and session strategy
HTTP clients can configure HTTP, HTTPS, or SOCKS proxies directly. Browser tasks can set a proxy when Playwright launches the browser. Managed APIs, remote browsers, and MCP are integration patterns that other services may provide; follow the selected service’s interface. These patterns do not establish corresponding MiyaIP product features.
For public APIs, datasets, or tests, evaluate a data center exit first. Static ISP exits can suit long-lived regional sessions. Choose residential or mobile exits only when the workflow requires end-user or cellular network characteristics. Select by workflow requirements rather than IP pool size.
Select routes in the orchestration layer using stable tenant, workflow, and session identifiers. Keep the exit unchanged during a stateful task, and isolate cookies between customers. The browser context preserves local state; the upstream proxy’s fixed or sticky configuration determines exit continuity. This example compares the actual exits before and after the task.
Install and run the Playwright example
1
Install the runtime dependencies
Install the Node.js project dependency and Chromium in a new working directory.Download ai_agents.mjs and retry_after.mjs, and save them in the same directory. The example uses the Chromium installed by Playwright.
2
Configure the proxy, target, and allowlist
Replace these placeholders with your extracted proxy details. This example uses an authenticated HTTP or HTTPS proxy and sets the server address separately from credentials.Inject real credentials through your secret-management tool. Update
ALLOWED_HOSTS when changing the target; separate multiple approved hosts with commas. The script also permits api.ipify.org for exit checks before and after the task. Targets and browser requests must use approved HTTPS hosts on the default port. Keep proxy credentials out of prompts and logs.3
Save the complete code
One browser launch uses one proxy route, and one context carries the logical session. The script reuses one page for all three steps, blocks network requests outside the allowlist, and closes the context and browser after completion or failure.
4
Run and inspect this task's results
outcome, target status, steps, retries, durationMs, masked exitIp, and sameExitAcrossTask. The current run’s title, heading, and titleMatchesHeading are saved to output/agent-result.json. Different title and H1 values do not by themselves indicate a network failure; apply the target’s data rules.The exit code is 0 when all three steps finish and the exit remains the same, 1 for an exit change or other failure, and 2 when the task must be deferred. No successful result is prefilled; use your actual run’s output.Retry and resume tasks
Each navigation makes at most 2 attempts. Navigation, default page-operation, and browser-launch timeouts are 30, 15, and 30 seconds. The cumulative retry waiting budget is 10 seconds per task. ValidRetry-After seconds or HTTP dates for 429, 500, 502, 503, and 504 are preserved in full; they are not shortened to 10 seconds. Only missing or invalid headers use bounded exponential backoff.
If the delay exceeds the remaining budget, or the final attempt still returns a transient error, the script reports outcome=deferred, a UTC retry_at, and a reason, then closes the browser and exits. Resume at or after retry_at in your orchestration layer; the example does not create a schedule. Dates outside the runtime’s supported range stop execution with retry_after_out_of_range and require manual rescheduling.