What if n8n has no node for the site?
Start with the site's approved API if it exposes the action you need. If the task depends on a rendered control or a signed-in page, connect a browser runtime to n8n. The workflow can call the browser through HTTP and validate what comes back. An AI Agent can call that workflow as a tool, while ordinary nodes enforce the allowed action and decide what to do with the receipt.
Take a confirmation button in a test portal. The workflow needs to know which record was confirmed and whether the status really changed. A browser can click and read the UI. n8n should keep the operation ID, validate the returned state and route a failed response to a read-back step. Otherwise a lost response can look like a failed click, even after the record changed. Browser automation tools Search and browser control
Separate the workflow from the browser
| Layer | Job | Output to keep |
|---|---|---|
| Parent workflow or AI Agent | Choose an allowed operation and pass one approved request | Operation ID and target |
| Browser sub-workflow | Validate the input, call the browser, check the output and route failures | Structured receipt or review status |
| Browser runtime | Open the intended page, verify the visible record, act and read back | Fixture or record ID, starting state and observed final state |
| Application or durable receipt store | Resolve an uncertain result and prevent duplicate writes | Previous confirmed result or an explicit unknown state |
An HTTP Request node can call a browser service, but the browser runtime determines what page opens and what account it can use. Give the workflow a bounded operation, such as “confirm this test record,” and let the executor choose the test page from trusted configuration. A tool that accepts any URL and arbitrary instructions grants more access than this workflow needs. Check the session before acting on a signed-in page. Connect to an existing browser Check a signed-in session
One user in an n8n discussion distinguished extracting data from interacting with page controls. Another discussion focused on what happens when the same workflow runs twice. Together they point to two checks worth doing early. Choose the right runtime and give every write a stable identity. Browser automation discussion Idempotency discussion
Import a small browser receipt workflow
Download the n8n workflow JSON and the local Tabbit fixture adapter. The example uses a local n8n installation, Node.js and the installed Tabbit CLI on the same computer. It clicks a button on a synthetic page with no account or external site. Start the adapter in one terminal, then import the JSON into n8n and run Manual Test.
node tabbit-fixture-adapter.mjsThe adapter listens on loopback port 3219. The workflow uses that address from the n8n process. If n8n runs in a container or on another machine, its localhost refers to that environment. Set up an authorized connection to the executor before changing the address in the two HTTP nodes. Cloud-agent localhost example
The workflow includes Workflow Tool Input for sub-workflow calls. On a parent AI Agent, add Call n8n Workflow Tool, select the imported workflow and map operation_id and scenario. For this fixture, pass one item per call. Keep the operation ID in an ordinary workflow node. In production, derive it from the source record and the intended action, rather than asking the model to invent a different key on each attempt. Call n8n Workflow Tool n8n sub-workflow data flow
Validate the receipt before routing it
The workflow checks the HTTP status, exact operation ID, expected fixture ID, starting OFF state, final ON state and a write count of one. A response that says “success” without the expected fields goes to review. The agent can summarize the receipt for the user, but downstream nodes should branch on the validated fields.
{
"operation_id": "E09-lost-response",
"outcome": "reconciled",
"receipt_source": "read_back",
"http_status": 200,
"fixture_id": "E09-FIXTURE",
"state": "ON",
"writes": 1,
"replay": false
}The http_status in that receipt belongs to the status lookup. Keep the original failed POST status in the execution log as separate evidence. The HTTP Request node reference documents returning the complete response and handling HTTP errors. If a transport error produces no status, the workflow should also treat the result as unknown.
Test what happens after a failed response
| Scenario | What the workflow checks | What it should return |
|---|---|---|
| Normal response | POST returns a matching record and observed ON | confirmed, one write |
| Lost response after a change | POST reports 503, then GET finds the same operation and ON | reconciled, one write |
| No matching state | POST reports 503, then GET cannot find the operation | needs_review, no automatic resubmit |
| Same ID after a confirmed change | Executor returns the stored receipt | Same result, one total write |
The adapter holds fixture state in memory. It is suitable for a local demonstration. A production workflow needs a durable operation record, unique keys and a way to read state after the executor restarts. Before a browser write, record the intended action and approved target. If the action is already confirmed, return that result. If it is in flight or unknown, look it up or escalate. A new random ID on every retry makes those checks ineffective.
The safest recovery step after a timeout is usually a read. Look for the destination record, existing confirmation or receipt. Retry a write only when the application can enforce the same idempotency key, or a person has verified that it did not occur and authorized another attempt. n8n error handling How a real form workflow verifies saved records
We imported the downloadable workflow into n8n 2.46.6 with Node.js 24.16.0. A separate local caller invoked it with one input per run. The first pass returned confirmed (200), reconciled (503 then 200) and needs_review (503 then 404). The adapter recorded two clicks in Tabbit. Repeating the same IDs returned the stored receipts for the two completed operations and left the third for review, with zero additional clicks. The test used a synthetic page and did not call a language model.
Start with one action and one assertion
Run the manual test before adding an AI Agent. Confirm that the normal result, read-back and review outcomes are visibly distinct. Add a model only after the workflow can enforce the same contract on every call. Choose a read-only task first when the browser needs a real work account. First browser-agent task What an AI agent does
FAQ
Can an n8n AI Agent use a browser without a node for the site?
Yes. Register a bounded browser sub-workflow as a tool, or call a browser service with an HTTP Request node.
Is an HTTP Request node a browser?
It calls an HTTP endpoint. A separate browser runtime provides page state, clicks, rendering and the authorized session.
What should a browser return to n8n?
Return an operation ID, outcome, record or fixture ID, observed state and enough source evidence to verify the result.
Should I retry a failed browser submission?
Read back the target state by operation ID before retrying a write. If the result is uncertain, pause for review.
Does a retry need a new operation ID?
Reuse the stable ID for the same intended operation. Reserve a new ID for a different action or record.