Submit a prior authorization on a payer’s own provider portal, such as the UnitedHealthcare Provider Portal, and capture the authorization reference number and status the payer shows back. For the payers whose authorizations live only behind their own front door.
Go-live in as little as 30 minBrowser agentCustomer portal login
We map your process, volume, and exception paths, then recommend a practical first scope.
Building internally? Read the docs →
Overview
Some payers put prior authorization behind their own provider portal, with their own login, their own request tool, and their own status screens. This workflow runs that flow end to end: the agent signs in, checks whether an authorization is even required for the member and procedure, and if it is, files the complete request and captures what the payer says back, the reference number and the status.
If the payer’s own check shows no authorization is required, the run stops there and reports that determination with the portal’s exact wording. That’s not a failed run; it’s a submission you didn’t have to make, on record.
How Asteroid runs this workflow
A PA request enters the queue, Asteroid signs in to the payer's own portal, runs the requirement check, files the complete request, and the reference number and status write back to your work queue, and anything the notes can't answer stops for your staff instead of being guessed.
How it actually runs
Each run returns the reference number, the status, and the exact label of anything it couldn’t answer. One authorization per run, every run logged.
A PA request with patient, payer, service, provider, and available clinical data enters the queue
Confirmation back in your PA work queue
The reference number, the payer's displayed status (pending, approved, in review), and any payer messages write back to your work queue, one authorization per run.
Clinical question the notes miss: The payer's exact question returns reported by name; your clinical staff answer it once, with the chart open, as do peer-to-peer requests and members the portal doesn't recognize.
Closing the loop
Nobody on your team reads this JSON. Your system does. Each run delivers its record wherever the work already lives, and the loop closes on its own: requests in, records back, no one in the middle.
{ "determination": "auth_not_required", "portal_message": "No authorization is required for these procedure codes.", "member_id": "W••••••04", "procedures": [ "CPT 99213", "CPT 20610" ], "checked_at": "2026-07-16T14:02:11Z"}A prior auth that was “definitely submitted” but has no reference number attached is a follow-up phone call waiting to happen: someone re-searching the portal, re-verifying the member, holding for the payer. This workflow treats the payer’s reference number and displayed status as the point of the exercise. Every submission ends with both captured, so follow-up starts from evidence instead of from memory, and the status conversation with the payer, if one is ever needed, starts with a number they recognize.
At scale
Each run files one request, which keeps the unit of work auditable. At queue scale, runs execute in parallel across the payers whose auths live on their own portals, alongside the clearinghouse-style submission workflow covering the multi-payer portals, and staff work the exceptions from both. Submission and status are part of the prior authorization workflow library; for the production pattern, see the prior authorization case study. The same discipline extends across the rest of the family: radiology PA on imaging-review portals, drug PA on ePA portals, high-volume queues, and the long tail of IPA portals.
Human in the loop
Runs handle member and clinical data on HIPAA-compliant, SOC 2 Type II infrastructure under a BAA, with an audit trail per authorization. Details on the security page.
A missing required field.
The run fails naming the field, before anything is filed.
A clinical question the notes don’t answer.
Left blank and reported, or if it blocks submission, the run stops naming the exact question.
A member or procedure the portal doesn’t recognize.
Reported with the portal’s wording, rather than forced through.
A review-summary mismatch.
If the summary doesn’t match the inputs, it does not submit.
Questions
Payer-portal submission is one workflow in the prior authorization workflow library. Every authorization stuck in a manual portal queue is a service that can’t be scheduled and revenue that can’t be booked.
Disclaimer
Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.