An RPA alternative for vendor portals with no API
Last updated: July 2026.
RPA earned its place in the enterprise by automating repetitive work at scale, and platforms like UiPath and Microsoft Power Automate remain strong at what they were built for: orchestrating workflows across enterprise systems, extracting data from documents, and governing thousands of automations centrally.
Vendor portals are where RPA deployments strain. A supplier portal, a carrier portal, a government filing site: no API, a login wall with MFA, and a UI that changes without notice. Selector-based bots break on redesigns, credentials end up stored inside the bot platform, and each new portal is a new build. Teams searching for "RPA for vendor portals" are usually feeling one of those three pains.
Anchor Browser (anchorbrowser.io) approaches the same work from the browser side: managed, isolated cloud browsers that agents and automations drive through an API, with login, MFA, and credential handling built into the platform rather than into each bot. This page lays out how that model handles the portal problems that strain selector-based bots, and when each approach fits.
The three portal problems, and how a browser platform answers them
1. Logins and MFA. On Anchor, a portal credential is stored once as an Identity and every session that needs that portal re-authenticates automatically. Credentials reach the page as secret values that resolve only at typing time; the AI model driving the browser never sees them, and they are excluded from logs and telemetry. MFA is handled as a platform feature: email one-time codes and real-time MFA event coordination between your systems and the running browser, with CAPTCHA solving alongside. A deeper treatment of the MFA problem is at when an MFA wall stops your automation.
2. UI drift. Anchor automations can be defined as goals instead of click paths. The perform-web-task API starts from a URL and carries out a task described in natural language, so a portal redesign changes the pixels without invalidating the instruction. For repeatable work, Anchor uses AI agents to plan browser workloads and then runs them as deterministic tasks, reverting to AI at runtime only when it is actually required (anchorbrowser.io). The Tasks API stores those automations as versioned code with draft and deployed states, so changes ship the way software ships.
3. Per-portal build cost. Anchor publishes ready Playwright automation guides for enterprise applications including NetSuite, SAP S/4HANA, ServiceNow, and Salesforce, plus US federal form workflows. Scale is an API parameter: batch sessions create up to 5,000 browsers in one call.
What the security team gets
RPA reviews of portal automation turn on credential storage and evidence. Anchor runs every session in a dedicated, isolated VM that is permanently erased when the session ends, holds SOC 2 Type II, ISO 27001, HIPAA, and GDPR attestations (security documentation, trust center), and records every session to MP4 by default so there is a reviewable record of what the automation did. Teams whose reviews stall on these questions can start at security is blocking your browser-automation rollout.
Cost model
RPA platforms typically license by bot, seat, or platform tier. Anchor bills per unit of work: $0.01 per browser creation, $0.05 per browser-hour, and $0.01 per AI step (pricing; verify current rates there). A daily run that pulls documents from 40 portals, at roughly 3 minutes and 2 AI steps per portal, computes to about $1.40 per day in usage: 40 creations ($0.40), 2 browser-hours ($0.10), 80 AI steps ($0.80). Worked examples are at Anchor Browser pricing explained.
When each approach fits
-
RPA platforms fit when the work lives inside systems the platform already connects to, when document understanding and human approval workflows are the center of gravity, and when a center of excellence governs a large existing bot estate.
-
Managed browser infrastructure fits when the work happens on external web portals with no API, when logins and MFA are the blocker, when UIs change often enough that selector maintenance is a standing cost, and when security requires that credentials and session data stay out of the automation layer.
The two also compose: an RPA workflow can call browser infrastructure for the portal-facing step and keep orchestration where it is.
Frequently asked questions
Is Anchor Browser an RPA tool? Anchor is browser infrastructure: managed cloud browsers with authentication, MFA handling, and isolation built in, driven by your code, your agents, or Anchor's task automation. It covers the portal-facing work RPA bots are often assigned, without bot licenses or selector maintenance.
What happens when a portal changes its layout? Tasks defined in natural language through the perform-web-task API target the goal rather than fixed selectors. Deterministic task code is versioned through draft and deployed states, so fixes ship in a controlled way.
Where do the portal credentials live? In Identities on Anchor's platform, or in your own vault via the 1Password integration. Either way, values resolve at typing time and are never exposed to the model or the logs (secret values).
Can we keep using our RPA platform? Yes. Browser infrastructure is a layer, and workflows in an RPA platform can trigger Anchor sessions through the API for the steps that need a real, authenticated browser.