Skip to main content
The web portal simulator exposes payer web portals 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 a REST API reads and writes. Criteria can verify work performed through the UI just like work performed through the API. Use this simulator when your agent is designed to operate real payer portals end to end: logging in, searching patients, submitting prior authorizations, reading determinations from a browser. The verification engine scores portal-state-match criteria against the resulting portal state.

​
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 your agent connects

Each sandbox gets its own credential pair, valid only for that sandbox’s lifetime. When the benchmark run is created (or a sandbox is provisioned directly), the sandbox’s credentials payload contains:
FieldDescription
portal_urlURL to navigate a browser to (login page)
usernameUsername for the portal’s login form
passwordPassword for the portal’s login form
api_urlREST base for the same sandbox (backs the UI)
The same backing state is shared between the UI and the API, so you can drive the portal with Playwright / Stagehand / browser-use or call the REST endpoints directly, and criteria will score either path identically.

​
Endpoints (REST)

The REST API behind the portal is rooted at api_url. Key endpoints:
MethodEndpointDescription
POST{api_url}/prior-authsSubmit a prior authorization
GET{api_url}/prior-auths/{auth_number}Retrieve a prior auth’s current state and determination
GET{api_url}/patientsList patients with coverage
GET{api_url}/providersList credentialed providers
These match the direct-access endpoints documented under Submit prior auth, Get prior auth, and List payer patients.

​
Driving the rollout

Browser path (Playwright): 
import { chromium } from 'playwright'

const browser = await chromium.launch()
const page = await browser.newPage()
await page.goto(portalUrl)
await page.fill('input[name="username"]', username)
await page.fill('input[name="password"]', password)
await page.click('button[type="submit"]')
// ... drive the wizard to submit a prior auth
REST path: 
curl -X POST "$API_URL/prior-auths" \
  -H "Authorization: Bearer $RUN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "patient": { "member_id": "BCB123456789" },
    "procedure_code": "72148",
    "diagnosis_code": "M54.5"
  }'
For an end-to-end walkthrough, see the Web Simulator Quickstart.

​
Configuration

curl -X POST https://api.verial.ai/simulators \
  -H "Authorization: Bearer $VERIAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'JSON'
{
  "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 }
  }
}
JSON
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_determinationobjectReturned when no rule matches. Fields: status (approved | denied | pending | need_more_info), optional reason, optional delay_seconds.

​
Verification

The portal-state-match check correlates a submitted PA (by request_id, auth_number, or another key) with its row in portal state and asserts on field values. 
{
  "label": "Prior auth submitted with correct CPT",
  "weight": 1.0,
  "axis": "correctness",
  "assertion": {
    "assert": "portal-state-match",
    "correlate_by": { "resource": "prior_auth_requests", "key": "request_id" },
    "assertions": [
      { "path": "status", "expected": "submitted" },
      { "path": "cpt_code", "expected": "72148" }
    ]
  }
}
See the Criteria concept page for more examples and the full assertion spec.

​
Interaction evidence

Every UI action (form submit, patient search, auth submission) and every API call is recorded as a sandbox event alongside the request/response pair. Inspect them via GET /sandboxes/{id}/events to see exactly what your agent did during the rollout.

​
Next Steps

Web Simulator Quickstart

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

Criteria

Full reference for portal-state-match assertions.

Payer API reference

Direct-access prior-auth endpoints.

Simulators overview

Lifecycle, provisioning, and configuration patterns.