How to Automate a Website Without an API

You can automate a website without an API by treating the rendered interface as the operational surface. The agent reads the current page, identifies a stable target, performs an explicit browser action and verifies the resulting state.

Choose the browser path when the interface is the contract

Browser automation is useful when a service exposes no API, when the API omits the workflow you need, or when the browser includes business logic that is difficult to reproduce elsewhere. Common examples include internal portals, supplier dashboards, administrative tools and legacy systems.

Start with a bounded workflow. Write down the starting page, required session, intended outcome and evidence of success. This turns a vague request such as "update the account" into observable browser states.

Observe the rendered page

An agent needs more than page text. It needs to know which controls are visible, which fields belong together, which dialog is active and whether an element is currently actionable.

With E2LLM, the agent can use list_tabs to find the right browser tab and sifr_capture to capture structured page state. Focused exploration can retrieve more detail around a target without repeatedly sending the entire page.

Act through stable targets

Prefer visible labels, roles and the current structured state over brittle coordinates. Fill fields deliberately, preserve the order required by the interface and treat submit, delete, purchase and permission changes as consequential actions.

A practical loop is:

  1. Capture the current state.
  2. Locate the target and its surrounding context.
  3. Perform one coherent action.
  4. Capture again and compare the result.
  5. Continue only when the expected state is present.

This loop also makes recovery clearer. If the page changed, recapture. If a validation error appeared, read it before retrying. If the target disappeared, return to observation rather than replaying an old coordinate.

Keep human review where consequences matter

An agent can prepare a form, a draft message or a set of changes while a person retains the final submit decision. The right boundary depends on the workflow. A search or navigation step can often run freely. A payment, legal acceptance or irreversible deletion deserves explicit confirmation.

Test the failure paths

Browser workflows fail through expired sessions, popups, validation messages, partial loads and changed layouts. Include at least one failure case in the initial test. Verify that the agent notices the new state and stops or adapts safely.

Scheduling, retry policy, secrets and durable audit records usually belong to the surrounding agent or workflow system. The browser layer should provide current perception and precise actions; the orchestrator decides when the work runs and what happens next.

Example: update a supplier record

Suppose an internal portal has no API for changing a supplier's delivery window. The workflow begins with the supplier identifier and approved new dates. The agent opens the authenticated portal, searches for the supplier, captures the record and compares the current values with the request.

It fills the new dates and stops at the save boundary for review. After approval, it saves once, recaptures the record and returns the displayed values plus any confirmation reference. If the portal reports a conflict, it returns the current state instead of overwriting it.

Common questions

Is browser automation the same as screen scraping?

Screen scraping usually extracts information. Browser automation also navigates and changes state. Reliable automation therefore needs action targeting, authorization boundaries and post-action verification.

How do I keep a layout change from breaking the workflow?

Use current labels, roles and structured context rather than fixed screen coordinates. Capture again when the state changes, and treat a missing target as a reason to re-observe rather than to guess.

When should I stop and request an API?

Prefer an available, supported API for stable machine-to-machine operations. Use the browser where the interface is the only complete operational path or where the workflow inherently depends on rendered state.

Copy this instruction into your AI

Use E2LLM to automate this website workflow without an API.
1. Call list_tabs and identify the intended tab. Ask me if more than one tab could match.
2. Capture the current page with sifr_capture.
3. State the target control and the evidence that it belongs to this workflow.
4. Perform one reversible action at a time and verify the resulting page state.
5. Stop before submit, purchase, deletion, permission change or legal acceptance and show me the prepared state for approval.
6. If the session expires, the target is ambiguous or the outcome is uncertain, stop and report the current state without retrying.
Goal: [describe the exact outcome]
Starting page: [describe the expected page]
Success evidence: [describe what the browser must show]

Connect E2LLM to your AI

Apply the method to safe online form filling. For a recurring read-only task, monitor authenticated pages for changes.