Recordings & Grounding

The recorder captures DOM interactions — clicks, typing, navigation, selections — not your screen. This makes it more robust than screen recording (no pixel-matching failures), more private (we never see your screen), and portable across different screen sizes and resolutions.

Alongside the interaction trace, the recorder captures the network calls the page makes while you work — the private JSON API behind the rendered HTML. That second layer is what lets rtrvr.ai turn a recording into a subroutine that hits the endpoint directly instead of replaying clicks. See From Recording to Subroutine below.

You do not have to record by hand. Ask for the tool in one sentence — "build me a tool that logs into app.example.com and returns this month's usage credits" — and the agent arms the recorder, drives the page so it issues the request that carries the data, stops the recording, generates the tool from it, saves it, and calls it once to verify before reporting back. If the site needs a sign-in, the agent asks you to sign in in that tab first (never for a password in chat). To record manually:

• 01

  Click the Record button in the side panel toolbar (or search to name your recording)

• 02

  Perform the task naturally in your browser — click buttons, fill forms, navigate pages

• 03

  Optionally narrate what you're doing (add text annotations the agent can reference)

• 04

  Click Stop when complete

• 05

  Select the recording in chat to give the AI the perfect example

Providing a recording demonstration dramatically increases task completion rates. For complex multi-step forms and interactions that are hard to describe in words, a recording often outperforms even the most detailed prompt. Record once, use forever.

Because the recorder sees the page's own XHR/fetch traffic, it can do more than mimic your clicks. The AI Tool Generator reads the captured calls and compiles the flow into an AI Subroutine — a saved, callable tool that hits the underlying endpoint directly. Once generated it is deterministic code: no model call, and no tokens, per run. See AI Tool Generator and the writeup on zero-token deterministic automation.

Watch a recording become a reusable Subroutine, then follow the four steps below.

• 01

  Record the task once — click through the flow you want automated

• 02

  Open the recording and generate a tool from it

• 03

  The generator ranks the captured calls, picks the one that actually carries the data, and writes a runner for it

• 04

  Save it, then call it with @toolName, from workflows, schedules, and triggers, or over the hosted MCP server

When the tool needs you signed in to the site, the agent also makes it cloud-ready in the same run: it asks once whether to sync that site's login to your cloud browser, so the scheduled or API-triggered runs work with Chrome closed. Decline and the tool still gets built — the agent just tells you those runs will need this browser open. Both questions (sign in, sync) come up before anything is saved, so answering them never builds a second copy of the tool or a duplicate schedule.

How the Generator Picks a Strategy

Not every endpoint is safe to call directly. rtrvr.ai classifies each captured request by the auth evidence in its headers, then chooses where the request runs and whether it is replayed at all. Requests that carry a client-computed signature are never forged.

Replay means the subroutine issues the request itself. Harvest means it lets the page issue its own signed calls and intercepts the responses, then transforms them. Either way you get the JSON — harvest just refuses to forge a signature it cannot legitimately compute.

Does Auth Survive the Tab Closing?

Yes for session-backed endpoints, but not by storing your session. Cookies are never replayed as a literal header — cookie and set-cookie are stripped from every generated request template. Instead, a cookie- or session-backed subroutine executes inside a real logged-in page: the runtime opens or reuses a tab on that origin and issues the request with credentials, so the browser attaches the current cookies itself.

• 01

  The subroutine stays callable after you close the tab, because invoking it opens one. What it depends on is the session, not the tab.

• 02

  If you are logged out, it fails the way a logged-out user would — there is no stored credential to fall back on.

• 03

  Bearer tokens and API keys captured in the recording are replayed verbatim from a background worker with no tab at all — but only while that token is valid. When it rotates or expires, regenerate the tool or re-record.

• 04

  In the Cloud, enable cookie sync in the extension so headless browsers open the same logged-in session.

• 05

  Secrets are redacted at the prompt boundary — the model that writes your tool sees [REDACTED:x-api-key], never the value. The runtime substitutes the real captured header at call time, and captured values always win over anything the model wrote.

Signed, CSRF, and HMAC'd Parameters

CSRF is handled rather than replayed. A stale x-csrf-token copied out of a recording would 403 on the next run, so requests carrying one are executed in the source tab where the application's own current token applies. The same holds for double-submit and same-site session patterns.

Client-signed and HMAC'd requests are deliberately not replayed. When a captured request carries a signature the client computed — Twitter/X transaction IDs, TikTok's x-bogus / x-gorgon / x-khronos, or a generic x-request-signature — replay is prohibited and the generator falls back to harvest. Forging those would break the moment the site rotates its signing algorithm; harvesting the page's own responses does not.

Every replay is validated before it is trusted. A 401, 403, 407, 419, or 440, a login interstitial, or unexpected HTML where JSON was expected marks the attempt failed and retries it inside the source tab — rather than quietly handing you a login page as if it were data.

If a Token or ID Is Invalid

First note when the error appears. If generation fails before a draft tool opens, refresh your rtrvr sign-in. If the draft saves but its first run fails, the target site may require a current session, token, or request ID that the generated Subroutine did not carry correctly. Allowing cookies helps only when that site actually uses cookies for authentication.

• 01

  Confirm the extension and Cloud dashboard are signed in to the same rtrvr account. A Workspace shares credits; it does not merge member sign-ins, target-site sessions, Google connections, or recording libraries

• 02

  Open the target site in a normal Chrome tab, sign in again, reload it, and complete the action once by hand

• 03

  Make a new recording from that fresh session, generate a new Subroutine, and test it on one item before adding it to a larger workflow

• 04

  For a Cloud run, sync cookies only after the fresh sign-in so the cloud browser receives the current session

• 05

  If the same error returns, stop retrying and send support the exact error text, the run link, the recording or Subroutine name, the target site's domain, and the email used for the Workspace. A repeatable failure may be in the generated request rather than your login. Never send a password, cookie, API key, or token

Recordings are a shared primitive — they're created in the extension but reusable across every rtrvr.ai surface. When you use a recording in a workflow, that recording is automatically bundled with the workflow artifact.

Recordings sync across your devices when logged in. You can organize, share them via URL with teammates, or import recordings from others.

• 01

  View all recordings from the Recordings section in the side panel, or from the Recordings panel in the Cloud dashboard — each recording there has a "Use in a run" action that preselects it in the composer

• 02

  Share via URL — recipients can import with one click

• 03

  Recordings bundle with workflows when shared, so teammates get the full context