Ask a claims adjuster, a licensing analyst, or a compliance ops team where their real system of record lives, and the answer is rarely an API. It's a portal—a state licensing board's filing system, a payer's claims dashboard, a carrier's underwriting console—built years ago for a person at a desk, not for machine integration. Regulated industries run on more of these screens than almost any other sector, and that's precisely where API-first automation strategies stall out.
Why the API Never Arrives
It's tempting to assume every enterprise system will eventually expose a clean API. In regulated industries, that assumption breaks down for structural reasons, not just slow vendor roadmaps. Portals built to satisfy a specific regulatory filing requirement are often maintained by a third party with no incentive to open an integration surface. Even where an API exists, it frequently covers a fraction of what the UI can do—read-only status checks while every state-changing action still requires a human clicking through the same form the portal was designed around. And in workflows where the screen itself is the auditable record—a filed form, a confirmation page, a timestamped submission—a JSON response can't stand in for what a regulator or auditor expects to see.
That leaves browser automation as the only path in, which changes the requirements. A scraper that grabs public data can afford to be disposable. Automation that submits a claim, updates a policy, or files on a regulated portal has to behave like production infrastructure that a compliance team can stand behind.
What That Requires in Practice
Three things tend to separate a portal automation a compliance team will actually sign off on from one that quietly becomes a liability.
Credentials that aren't hardcoded into a script. Regulated portals almost always sit behind a login, and pasting a service account's password into automation code is the fastest way to fail a security review. Anchor's identities model lets you define an application's login flow once and attach a stored identity to a session instead of the automation ever seeing the raw credential:
const session = await anchorClient.sessions.create({
identities: [{ id: "state-licensing-portal-identity" }],
session: {
recording: { active: true },
live_view: { read_only: true },
tags: ["licensing-filing", "compliance-review"],
},
});
// Session starts already signed in; no credential ever
// passes through the automation script itself.An audit trail that doesn't depend on trusting the automation's own logs. session.recording.active is on by default and captures the full visual run as an MP4—independent evidence of what actually happened on the screen, which matters when the question isn't "did the script return success" but "what did the portal actually show at 2:14pm." Tag sessions by workflow and case ID so a specific filing's recording is easy to pull months later.
A human able to watch without being able to interfere. A live_view set to read_only: true gives a compliance reviewer or a second set of eyes a real-time window into the session—useful for high-stakes submissions where someone wants to watch a filing go through without holding the mouse.
Treat the Portal Like It's Production
None of this is about working around a portal's defenses—it's the opposite. These are authenticated sessions, using credentials the automation is explicitly provisioned to use, on systems the team already has standing access to. The goal is a run that a compliance officer can reconstruct after the fact as easily as they'd reconstruct a person's actions, not a black box that happened to return a 200.
If your team is automating claims, licensing, or filing workflows that live behind a login and nowhere else, that's exactly the gap Anchor is built to close. Get an API key and bring the next regulated portal into the same governed session model your team already trusts for everything else.
