Cloudflare Browser Run automation can connect an AI workflow to a website when a supported API is unavailable or insufficient. That flexibility comes with a different operating burden: pages change, sessions expire and a completed click does not prove that the intended business action happened.
Prefer a supported API when it exposes the required operation reliably. Use Browser Run when the browser is the appropriate interface, with an authorized session, a bounded task and explicit checks of the resulting page or record. Stop on uncertain outcomes and reconcile them before repeating consequential actions.
Imagine an operations team downloading a supplier statement from a portal. The assistant must select the right account and period, obtain the file and verify its contents. A later workflow might upload a reconciliation note. Those are distinct scopes; permission to retrieve a statement does not imply permission to submit a document.
The design below is hypothetical. It does not claim that browser automation bypasses a portal’s access restrictions or that an AI model can safely improvise around every interface change.
Cloudflare Browser Run automation starts with interface choice
Cloudflare’s Browser Run overview describes the current service, formerly called Browser Rendering, including stateless actions and browser sessions. Choose the integration mode from the task rather than treating every operation as an open-ended agent session.
For a public screenshot or simple page extraction, a bounded request may be sufficient. A logged-in portal journey needs session handling, navigation checks and a clear completion condition. An API may avoid much of that page-specific work.
| Task requirement | Assess first | Why it matters |
|---|---|---|
| Retrieve a supported business record | Official API | Stable record identity and explicit responses |
| Capture a public page | Stateless browser action | Limited navigation and session state |
| Download from an authorized portal | Controlled browser session | Login and page-state transitions |
| Submit a consequential form | API or explicitly approved browser flow | Outcome and duplicate handling |
| Explore arbitrary sites | Narrow the task before implementation | Unbounded navigation is difficult to accept |
Document why the browser is needed. This makes a later migration to an API a conscious engineering choice rather than an admission that the original integration never had a stable contract.
Make the task narrower than the browser’s capabilities
The browser may expose buttons the automation must not use. Define permitted origins, accounts, records and actions outside the model’s prompt. Keep the workflow’s business authority in the application that starts the job.
For the supplier statement, the task contract can identify the supplier account, statement period and destination review queue. It should also define what to do if several accounts or periods match. Asking the model to choose the most plausible account is not an adequate resolution policy.
Separate reading and submitting. A download job should not acquire a generic “finish anything on this portal” instruction that could include changing details or accepting new terms. Unexpected consequential steps need the task to stop and report the condition.
Cloudflare’s Playwright integration guide is the implementation reference for that approach. Pin the selected package and compatibility configuration, and verify the features your workflow actually uses.
Use fresh page state to guide each transition
Check what the page currently shows before deciding the next action. A selector that worked on the previous page may refer to a different control after navigation or an error. Prefer meaningful labels and stable application identifiers where the site provides them.
An AI model can help interpret a page, but deterministic assertions should establish critical facts such as the selected account and requested period. If the expected control is absent, record the page state and stop rather than clicking a nearby element that looks similar.
After an action, verify the resulting state. Opening a download menu is not a completed download. A success banner may be useful evidence, but a file-retrieval task should also establish that the intended artifact was obtained.
Avoid timing the workflow around arbitrary long waits. Define the state you are waiting for and a bounded timeout. When it does not appear, the report should identify the failed transition and retain appropriate evidence for investigation.
Treat browser sessions as sensitive application state
A logged-in browser can carry access through cookies and other storage. Assign sessions deliberately and prevent one user’s task from inheriting another user’s authenticated state. A reusable session identifier is not proof that the current caller should use it.
Define login expiry and reauthentication handling. If the portal asks for a new login or an unexpected access grant, the automation should not treat that as permission to change the account’s security settings.
Limit retained screenshots and traces to what operators need. They can contain account details, source documents or session-related material. Give the evidence store its own access and retention rules rather than assuming diagnostic data is harmless.
Test logout and revocation as well as login. The application should know how an expired or removed portal account affects queued jobs and existing sessions. A task must not continue under another available account simply because that account remains signed in.
Verify downloaded and submitted artifacts
For the statement job, compare the file’s supplier, account and period with the task contract. Check the format and whether the contents are complete enough for the intended reconciliation. A valid PDF with the wrong period is still a failed task.
| Evidence | What it establishes | What it does not establish |
|---|---|---|
| Expected page loaded | Navigation reached a recognizable state | Correct record was selected |
| Download event | A file transfer started | The file belongs to the requested account |
| Parsed file metadata | Account and period can be inspected | Every business total is correct |
| Destination receipt | An upload was accepted | The destination applied the intended meaning |
For submission, identify an operation reference or resulting record that can be inspected independently. If the browser loses the response after clicking submit, do not repeat the click until the destination outcome is established.
Keep an explicit uncertain state. It is more useful than marking every timeout failed and immediately retrying, especially where the portal can create duplicate records or send a notification as a side effect.
Test changes and limits before promising a service
Include an expired login, a changed label, several matching records, a missing download and a lost response after submission. These tests show whether the automation can stop usefully when its assumptions fail.
Cloudflare documents Browser Run limits for the service. Verify them against the selected plan and integration method when designing concurrency and timeouts. Do not promise a throughput or session lifetime from an old tutorial.
The test report should separate portal failures, automation defects and application-policy refusals. Each has a different owner and response. A generic retry button should not be the only recovery mechanism.
When a site changes, rerun the relevant acceptance cases before restoring automatic processing. A model finding a new route through the page is not sufficient evidence that the route reaches the same account, document or business outcome.
Budget for maintenance of the journey
Browser integrations need an owner for changes in the destination interface. Include that work in the procurement decision. A cheap initial script can become expensive if no one notices it has been downloading the wrong report.
Request a GBP estimate with named portals, accounts, task variants, artifact checks and recovery requirements. Separate the initial journey from monitoring, test maintenance and support. State which unexpected steps cause a handoff to a person.
| Cost area | Question for the proposal |
|---|---|
| Session handling | How are login, expiry and account separation managed? |
| Navigation | Which page states are supported and asserted? |
| Validation | How is the actual artifact or destination record checked? |
| Recovery | Who resolves uncertain submissions? |
| Maintenance | How are portal changes detected and tested? |
We can assess the API-versus-browser boundary through our AI integration pilot . Request a browser-automation proposal with the portal, permitted task and evidence required to call it finished. That produces a supportable workflow rather than an impressive sequence of clicks.
Frequently Asked Questions
Is Browser Run the same service as Browser Rendering? Browser Run is the current name documented by Cloudflare for the service formerly called Browser Rendering. Use the current documentation and verify the selected integration method rather than copying old configuration unchanged.
Should we use browser automation if an API exists? Assess the supported API first. It may provide clearer record identity and operation outcomes. Use a browser where the required interface or task genuinely calls for it, and account for page and session maintenance.
Can an AI model repair every broken selector? No. A model may help interpret a changed page, but a new navigation path still needs to satisfy the task’s account, record and outcome checks. Stop when those facts cannot be established.
What proves a download succeeded? Obtain the artifact and verify that its account, period, format and relevant content match the task. A click or download event alone does not establish that the correct business document arrived.
Should we retry a form after a timeout? First establish whether the destination accepted it. A lost response can follow a successful submission. Use an operation reference or inspect the resulting record before repeating an action that could create another effect.
Can we reuse logged-in sessions? Only under an explicit account-isolation and authorization design. Confirm who owns the session, which tasks may use it and what happens after expiry or revocation. Do not let one user’s task inherit another user’s access accidentally.
What should a browser pilot deliver? It should deliver the supported journey, account and artifact assertions, failure evidence and an operator recovery procedure. Include interface changes and uncertain outcomes as well as the normal success path.