Introduction

WebRobotCloud (WRC) is a cloud-hosted browser automation platform. You write your script in Go or TypeScript, the SDK talks gRPC to our server, and a real Chromium runs the actual page somewhere in our infrastructure — behind a proxy, with a real browser fingerprint, in the region you asked for. No headless binary on your laptop, no browser farm to babysit.

The mental model

    your code                   WRC server                    the page
   +--------+    gRPC   +------------------------+   CDP   +------------+
   | SDK    |---------->| rent / drive / stop    |-------->| Chromium   |
   | (Go/TS)|<----------| proxy & fingerprint    |<--------| + iframes  |
   +--------+  results  +------------------------+  events +------------+

Every WRC script follows the same three-step arc:

1. Rent a session. The server allocates a fresh browser context, routes its traffic through a proxy (yours, or one from our pool if you leave the proxy fields empty), pins a browser fingerprint, and hands you back a sessionId plus a gRPC URL.
2. Drive it through the SDK: navigate, click, fill, wait, read the DOM, intercept network — every operation is a single gRPC call.
3. Stop the session when you are done. The server tears the context down so you stop holding resources you no longer need.

When to use WRC

Playwright and Puppeteer are testing tools — built for driving your own app, where the page is on your side. WRC is built for the opposite case: sites that actively push back.

Stealth plugins for Playwright / Puppeteer only patch the JavaScript surface — navigator.webdriver, plugin lists, a few canvas/WebGL overrides. The harder problem they can't touch is that those tools drive the browser through CDP, and modern bot vendors fingerprint exactly that: the Runtime.enable side-effects, the inspector handshake, the target-attachment pattern, the timing of CDP events. That signal is in the control plane, not the page, so no JS patch can hide it.

WRC drives the browser through its own native automation pipeline, not CDP. There is no DevTools connection for the page to detect, so the entire CDP-detection vector simply isn't there to begin with — on top of fresh fingerprints, real residential IPs, and human-shaped mouse/keyboard timing for every action.

Glossary

Four nouns show up on basically every page from here on. Skim them now, come back if a later page uses one in a way that surprises you.

• Session — one rented browser. It lives until you call Stop or until the rentDuration you booked expires. Each session is tied to one sessionId and one gRPC URL.
• Page — a single tab or popup inside a session. A session can hold several pages — for example when a click opens target="_blank".
• Frame — every page is a tree of frames. The main document is the root frame, each <iframe> is a child, and cross-origin frames (OOPIFs) are first-class members of the tree.
• Locator — your declarative "which element, under what conditions". The same Locator object works as a wait condition and as a click / fill / drag target.

How these docs are structured

These pages are written to be read top-to-bottom. Quickstart gets a working script onto your machine in under a minute. Core concepts then names the three SDK nouns you just used, so the rest of the API reference starts to feel like vocabulary rather than mystery. The Guides chapters that follow each pick one domain (waiting, networking, captchas, …) and go deep.

If you would rather skip prose and start clicking, jump straight to Quickstart — you can always come back here once the script runs.