Skip to main content
The web simulator exposes payer web portals that your agent can drive with a browser automation tool. Each portal is a pixel-faithful reproduction of a real vendor site (login page, navigation, form fields, workflow) backed by the same sandbox state the REST API reads and writes. Criteria can verify work performed through the UI just like work performed through the API. Use the web simulator when your agent is designed to operate real payer portals end to end: logging in, searching patients, submitting prior authorizations, and reading determinations from a browser.

​
Portal Catalog

PortalSlugUse case
RadMDradmdRadiology benefit management prior auth (Evolent). Multi-step wizard: patient lookup, physician, clinical questions, auth summary.
CoverMyMedscovermymedsPharmacy prior auth (ePA) across many payers. Draft management, formulary lookup, prescriber verification.
The slug goes in the config.portal field when you create the simulator.

​
How It Works

  1. You create a simulator with type: "Payer" and config.portal: "<slug>".
  2. You create a sandbox from that simulator. Verial provisions a fresh login (username + password) scoped to this sandbox.
  3. The sandbox’s credentials payload contains:
    • portal_url — the URL to navigate a browser to
    • username / password — credentials for the portal’s login form
    • api_url — REST base for the same sandbox
  4. Your agent opens portal_url, logs in, and drives the portal UI. All actions mutate sandbox state.
  5. When you’re done, tear down the sandbox or let the playground teardown handle it.
Each sandbox gets a unique credential pair. Credentials are valid only for that sandbox’s lifetime.

​
Quickstart

See the Web Simulator Quickstart for an end-to-end walkthrough: API key → create simulator → create sandbox → Playwright login.

​
Configuration

await verial.simulators.create({
  type: 'Payer',
  name: 'RadMD',
  config: {
    portal: 'radmd',
    determinations: [
      { match: { procedure_code: '70553' }, response: { status: 'approved' } },
      { match: { procedure_code: '70551' }, response: { status: 'denied', reason: 'not medically necessary' } },
    ],
    default_determination: { status: 'pending', delay_seconds: 0 },
  },
})
FieldTypeDescription
portal"radmd" | "covermymeds"Which portal skin to render. Determines the portal_url host and the UI the agent drives.
determinationsarrayRules that map a submitted PA (by procedure_code or patient_member_id) to a determination. First match wins.
default_determinationobjectDetermination returned when no rule matches. Fields: status (approved | denied | pending | need_more_info), optional reason, optional delay_seconds.

​
Interaction Evidence

Every call made through the portal UI (form submit, patient search, auth submission) is recorded as a sandbox event alongside direct API calls. List events with GET /sandboxes/{id}/events to inspect what your agent did during a rollout.

​
Next Steps

Web Simulator Quickstart

Provision a RadMD sandbox and log in from a browser in under 5 minutes.

Sandboxes

Full API reference for the credentials shape returned by each simulator type.