Automate a Website or Legacy Tool That Has No API: The Claude-Code-Plus-Playwright Browser Agent

The problem

A large share of real business work lives on websites that expose no API: a vendor portal you log into every week to download invoices, a government or compliance portal you re-key data into, a legacy SaaS tool your team is stuck on, a supplier site you check specs on, or an internal admin panel with no export button. Because there is no API to call, these tasks fall back to manual clicking, copy-pasting, and re-keying — slow, error-prone, and impossible to schedule. Off-the-shelf RPA and form-fillers exist, but they are either rigid (record-and-replay scripts that break the moment a page layout shifts) or sold as per-seat SaaS you rent forever. What is missing for most operations and finance teams is an agent that can look at a page, reason about it, and self-correct when something moves — without standing up an enterprise RPA platform.

Who it's for

Operations and finance teams stuck on legacy or no-API tools (vendor-portal invoice and report downloads, compliance portal data entry), procurement and data-entry-heavy businesses that re-key information between systems, e-commerce operators managing listings or back-office panels with no bulk export, and community or social managers who need light, scheduled engagement on platforms that offer no automation API. Best fit: an SMB or agency that wants to own the automation rather than rent another RPA seat, and has at least one technical owner to maintain it.

How it works

1. 1

   Scope the task and start in plan mode: in Claude Code, describe the exact website job in plain language (for example, 'log into this vendor portal every Monday and download last week's invoices as PDFs') and have it install the Playwright CLI and launch a real browser it can drive and screenshot.

2. 2

   Log in once, manually, and persist the session: complete any login, MFA, or cookie-consent step yourself in the launched browser, using a persistent browser profile (saved cookies) so the agent reuses that authenticated session on every later run instead of re-authenticating each time.

3. 3

   Let the agent script the steps from the live page, not from a brittle recording: Claude reads the actual DOM, identifies the fields and buttons, and writes a Playwright script to fill the form, run the lookup, or trigger the download — reasoning about the page rather than replaying fixed coordinates.

4. 4

   Build a self-correction loop: have the agent take screenshots, check whether it reached the expected state, and when a selector moved or a step failed, re-read the page and fix its own script until the run is reliable — this is what survives the layout changes that break record-and-replay RPA.

5. 5

   Add guardrails for production: cap retries and run time, log every run with screenshots for audit, handle the 'session expired / re-login needed' case gracefully, and keep one human-in-the-loop checkpoint for anything irreversible (submissions, payments, posting).

6. 6

   Schedule it and wrap it into a reusable skill: run the verified script headless on a cron schedule (or trigger it from your phone), and package the working flow as a named skill so the same agent can be pointed at the next no-API task without rebuilding from scratch.

Tools

The result

You get an agent that operates a no-API website the way a person would — logging in with a persisted session, filling and submitting forms, running lookups, downloading reports and invoices, and performing logged-in actions — but unattended and on a schedule. Because the agent reads the live page and self-corrects from screenshots, it tolerates minor layout changes that would break a record-and-replay macro, and because the login session is saved to a browser profile, it does not need credentials re-entered on every run. The practical outcome is that weekly portal downloads, recurring data entry, and spec lookups stop being manual clicking and become a scheduled, logged, auditable job you own — without buying an enterprise RPA platform or per-seat form-filler. Honest caveats: this is a moderate, maintained build (roughly 3 out of 5), not a no-code toggle — selectors and login flows still need a technical owner; you should keep a human checkpoint on anything irreversible; and automated engagement or posting on third-party social and community platforms is sensitive to those platforms' terms of service and is best kept human-in-the-loop, so treat it as a minor, ToS-aware sub-use rather than the headline.