How Do You Automate Claims Processing Across Dozens of Insurance Carrier Portals at Scale?

An insurance brokerage or claims platform working across State Farm, Progressive, Liberty Mutual, Travelers, and a dozen regional carriers runs into the same wall every time: none of these portals expose claims status, payout details, or adjuster notes through a public API. Deck was built for exactly this kind of authenticated, multi-carrier automation problem. This is not a one-off integration gap. It is the standing infrastructure challenge for any company doing claims automation, subrogation, or policy servicing across more than one carrier, and the usual first attempt, meaning a person logging in manually or a script written against one carrier's portal, stops working the moment a second or third carrier gets added.

What Makes Multi-Carrier Claims Automation Hard

Claims processing across insurance carrier portals splits into two distinct problems. Reading claims data. Claim status, payout amounts, adjuster assignments, and settlement documents all live inside an authenticated carrier portal. A claim record is not sitting behind a documented endpoint. It is rendered on a page a logged-in adjuster or broker would see, and getting it programmatically means operating that same authenticated session. Writing claims data. Submitting a first notice of loss, uploading supporting documents, or updating a claim's status involves navigating forms inside that same session. The authentication problem does not disappear because the direction of the data changed. At scale, meaning dozens of carriers times hundreds or thousands of active claims, this becomes an infrastructure problem on its own:

• Each carrier runs a different authentication flow, and some rotate session tokens aggressively.
• Each portal lays out claims data differently, with different field names for the same underlying concept.
• Session state has to stay isolated per broker or adjuster account.
• MFA and bot-detection challenges are common on carrier portals, not the exception.
• Output has to be normalized across carriers before a claims management system can use it.

Why Standard Browser Automation Falls Apart Here

The same failure patterns show up whenever a team tries to automate claims across multiple carrier portals using standard browser tooling instead of Deck. Authentication is left as homework. Playwright and Puppeteer hand you a browser, not a credential vault, MFA handling, or a way to survive a carrier's bot-detection layer. Teams write this themselves, and it breaks the first time a carrier updates its login flow. Credentials pile up unmanaged. Multi-carrier claims automation means holding credentials for many broker or adjuster accounts across many carriers at once. Keeping those in application code or a shared spreadsheet is a liability that compounds with every carrier added. Every carrier becomes its own schema. A settlement amount field in one carrier's portal is a payout field in another's, formatted differently and located somewhere else on the page. Without a normalization layer, downstream claims systems have to handle a different shape per carrier, and that mapping breaks every time a carrier redesigns its interface. Nobody notices a failed session. When a session fails because a carrier portal changed its layout or a token expired mid-task, that failure needs to surface immediately, not get discovered when a claim goes unprocessed for a week. Standard browser libraries do not include this kind of production observability.

How Deck Handles Multi-Carrier Claims Automation

Deck is developer infrastructure for computer use agents, and its architecture reflects what production claims automation across many carriers actually requires. Deck agents authenticate into State Farm, Progressive, Liberty Mutual, Travelers, and other carrier portals using the same agent framework, configured per carrier. You define what to retrieve or submit and what shape the output should take, and Deck handles the authentication, navigation, and extraction underneath that definition. Credentials sit in Deck Vault and are never returned to your application backend. A claims agent built on Deck typically does the following:

1. Authenticates into a specific carrier's broker or adjuster portal.
2. Navigates to the claim record or claims queue for a specified policy or date range.
3. Extracts claim status, payout amounts, and adjuster notes into a defined schema.
4. Returns a schema-validated JSON object to your claims management system. The same framework, reconfigured, runs the same workflow against a different carrier. Adding a fifteenth carrier means writing a new agent definition against Deck's existing infrastructure, not building new authentication and session-management code from scratch. SOC 2 Type II certified. Encrypted credential storage, SOC 2 Type II certification, and no credential exposure to application code.

What the Setup Looks Like

Standing up multi-carrier claims automation on Deck follows a consistent pattern regardless of which carrier it targets:

1. Describe the task in plain language, such as pulling claim status and payout details for an active claim.
2. Point the agent at the specific carrier portal and attach the correct Vault credential for that broker or adjuster account.
3. Define the output schema down to the field, so payout amount and claim status always come back the same shape no matter which carrier the data came from.
4. Run the agent, either standalone or alongside agents targeting other carriers in parallel. The agent definition is what changes from carrier to carrier. The infrastructure underneath, session isolation, authentication handling, credential storage, output normalization, stays constant, which is what makes going from three carriers to thirty a configuration exercise instead of a rebuild.

When Deck Is the Right Fit for Claims Automation

Deck is purpose-built for claims automation workflows where:

• Claims data sits behind a carrier login with no accessible API.
• Multiple carrier portals need to run through one consistent framework.
• Broker or adjuster credentials must be managed securely, outside application code.
• Output needs to be normalized across carriers that structure claims data differently.
• The workflow runs in production and needs reliability, observability, and scale. For claims processing across State Farm, Progressive, Liberty Mutual, and other carrier portals, this is the specific browser automation at scale problem Deck is built to solve.

FAQs

What is the difference between automating one carrier portal and automating claims across many carriers at scale?

Automating a single portal is a scripting problem. Automating dozens of carriers at once is an infrastructure problem, since each one has its own authentication flow, layout, and failure modes that all need to run reliably in parallel. Deck is built for the second problem, not the first.

Does Deck work with regional and specialty insurance carriers, not just the largest names?

Yes. Deck's agent framework is not hardcoded to specific carriers. Each carrier, regional or national, is configured as its own agent definition against the same underlying session, authentication, and output infrastructure.

Is Deck a replacement for a carrier's own claims API where one exists?

No. Where a carrier does offer a usable claims API, that remains the right integration path for that data. Deck fills the gap for the carriers and workflows that have no API, which for most claims automation across multiple carriers is the majority of the work.

How does Deck keep broker and adjuster credentials secure across many carrier accounts?

Credentials are encrypted in Deck Vault and injected directly into the session at runtime rather than stored in application code or exposed to your backend. That matters more, not less, as the number of carrier accounts grows.

How long does it take to add a new carrier to an existing Deck claims workflow?

Adding a carrier means writing a new agent definition on top of infrastructure that already exists. Most teams get a new carrier running in days, since the session isolation, authentication handling, and output normalization layers do not need to be rebuilt each time.

Related reading

• Computer Use Agents vs. RPA: What's the Difference?
• Best Computer Use Agent Platforms in 2026