How to Automate an Insurance Claims Portal Without an Official API

The problem with claims portals

If you work in insurance — as an adjuster, underwriter, or engineer on an automation team — you already know the answer to "does the portal have an API?" It's almost always no.

Guidewire PolicyCenter and ClaimCenter, Duck Creek, Majesco, and the dozens of legacy home-grown systems that carrier IT departments have been maintaining for 20 years were built in an era when the browser was the interface. There was no expectation that a machine would call the system — only a human sitting in front of a screen.

Today, AI agents need to read claims status, submit documentation, look up policy terms, and trigger approval workflows. They can't do any of it, because the front door is a login page and the back door doesn't exist.

What teams try first (and why it fails)

The obvious answer is browser automation. Selenium, Playwright, or one of the newer AI-driven computer use agents. You record a session, write some selectors, and automate the clicks.

This works exactly once. The moment the portal updates — a CSS class renames, a form field moves, the login flow adds an intermediate step — the script breaks. In enterprise software, portals update on vendor-controlled schedules. You don't get a changelog. You find out when the automation stops working in production.

The deeper problem is speed. Browser automation boots a full Chromium instance, renders every page, waits for JavaScript to execute, then performs each action one at a time. A workflow that takes a human 3 minutes in the browser takes an automated script 2-3 minutes as well — because it's still navigating the same UI. At scale, this costs money and time.

The request-layer approach

Every action a human performs in a browser sends HTTP requests to a server. Submit a claims form: one or more POST requests with the form data. Log in: a sequence of requests that exchange credentials for session tokens. Load claims status: a GET request that returns JSON or XML.

The browser is just a renderer. The actual data exchange happens at the network layer, and that layer is accessible without rendering anything.

Request-layer automation works by capturing those underlying requests — including the auth sequence, CSRF tokens, session cookies, and the precise headers the server expects — and replaying them directly. No browser. No rendering. No waiting for JavaScript. The portal receives exactly the same requests it would from a legitimate logged-in user.

The performance difference is significant. A workflow that takes 3 minutes in a browser can execute in 4-8 seconds at the request layer. That's not a rounding error — it changes what's feasible to automate.

The auth problem

Request-layer automation sounds simple until you look at how insurance portals actually handle auth. You're not dealing with a username and password that returns a JWT. You're dealing with:

• SSO flows that redirect through an identity provider (SAML, OIDC, or proprietary)
• CSRF tokens embedded in page HTML that rotate per-request
• Session cookies that have domain scoping and short TTLs
• Multi-factor authentication that requires a second factor on initial login
• In some systems, captcha on the login page

Automating each of these from scratch — for every portal you need to support — is weeks of engineering work per integration. And the moment the portal updates its auth flow, you start over.

The practical solution is to capture auth once from a real browser session, then reuse those credentials at the request layer. The human logs in normally, the session is captured, and the automation executes with that session. When it expires, the human re-authenticates once and the session is refreshed. No storing plaintext passwords, no service accounts, no shared credentials.

The team problem

Most enterprise automation approaches solve for one caller. A service account logs in, gets a session, and all automation runs under that identity. This creates real compliance problems in insurance:

• Audit trails show a service account, not the individual adjuster or underwriter who authorized the action
• Session sharing violates most carriers' terms of service
• A single compromised credential affects every automated workflow

The right model for enterprise teams is: one integration definition, each caller's own credentials. A claims adjuster in one office and an underwriter in another both call the same automation — but each call executes with their own session, from their own machine, leaving their own audit trail. No shared credentials, no compliance exposure.

What this looks like in practice

Here's the workflow for automating a claims status lookup on a legacy portal:

1. Capture once. An engineer runs the workflow in a browser while a traffic recorder captures every underlying request — the login sequence, CSRF tokens, the actual API call, and the response structure.
2. Build the integration. The captured requests are turned into a replayable sequence with variable injection (swap in the claim number, customer ID, whatever changes per call). Auth is handled automatically.
3. Each team member authenticates once. They log into the portal normally in their browser, export their session, and import it to the automation agent running on their machine.
4. Call from anywhere. The integration is now available via MCP (Claude, GPT, Cursor can call it directly), REST API, CLI, or scheduled workflow. Each call runs from the caller's machine, with their own session.
5. Self-healing covers portal updates. When the portal updates its request format, AI self-healing detects the failure at runtime, analyzes the error against the current portal state, generates a fix, validates it, and updates the integration — without a manual patch or a support ticket.

What you need to get started

If you have a specific portal in mind — a claims system, a carrier portal, a policy admin system — the fastest path is to describe it and get a scoping conversation. The questions that matter:

• What workflows do you need to automate? (Status lookup, document submission, approval triggers, data extraction)
• How does auth work? (SSO, direct login, MFA)
• How many team members need to call it, and do they each need their own credentials?
• Where does the output need to go? (MCP for AI agents, REST for internal systems, scheduled for batch runs)

Most insurance portal workflows we've seen — claims status, policy lookup, contract approval, document retrieval — can be live in days once the request chain is mapped. The mapping is the work; the ongoing execution is automatic.