Availity prior authorization: how to submit and track authorizations

Availity is not an insurer. It is the road, not the destination. When a payer tells your team to “submit the auth through Availity,” the payer is naming a delivery channel: Availity Essentials carries your request to that payer, and carries the payer’s response back. Every clinical judgment on the request, approve, deny, pend for records, belongs to the payer or to the benefit manager the payer delegates to.

That distinction is not academic. It determines who you call, what you fix, and whether you are wasting a week. This guide is written for billers and authorization coordinators who work Availity daily. Every section leads with the operative fact.

What Availity is

Availity is a health information network. Its provider-facing product, Availity Essentials, gives a practice one login and one set of screens for working with many different health plans, instead of a separate portal, password, and interface for each. Behind that login it also operates as a clearinghouse, moving standardized electronic transactions between provider systems and payer systems: eligibility and benefits inquiries, claim submissions, claim status, remittance, and, where the payer supports it, authorization requests and authorization status.

Place it on the map and the rest of the page follows. There are three parties in an Availity prior authorization, and only two of them decide anything:

• The provider. Builds the request: member data, provider identifiers, codes, and clinical documentation.
• Availity. Authenticates the user, validates the transaction’s format, identifies the payer, and hands the request over. Returns whatever the payer sends back. It does not read the clinical note, and it does not have an opinion about the note.
• The payer, or the payer’s delegated benefit manager. Applies coverage rules and medical-necessity criteria and issues the determination: approved, denied, or pended for more information.

So Availity holds no medical policy and publishes no clinical criteria, because it does not perform clinical review. The criteria that govern your request are the payer’s. If you are submitting an Aetna request through Availity, the standard being applied is Aetna’s, and the details live on the Aetna prior authorization page, not in Availity’s documentation. The same holds for Humana, Anthem, and the various Blue Cross Blue Shield plans. The practical benefit is worth stating precisely: Availity cuts the number of portals your team maintains and gives you one place to check status across several payers. It compresses the busywork around the decision. It does not compress the decision.

Which payers use Availity

Several large national plans use Availity Essentials as their provider portal, including Aetna, Humana, Anthem/Elevance, and many Blue Cross Blue Shield plans. That list is a starting point, not a rule. Two qualifications matter more than the list itself.

Participation varies by payer and region. Blue Cross Blue Shield is not one company; it is many independent licensees, and they do not all make the same portal decisions. A Blue plan in one state may run everything through Availity while a Blue plan in the next state runs its own portal. Never generalize from the plan you worked yesterday to the plan in front of you today.

Capability varies within a payer. A payer being “on Availity” tells you the payer is reachable there. It does not tell you which transactions are enabled for that payer, for that plan line, in your region. A payer may support eligibility and claim status through Availity while requiring authorizations somewhere else entirely, or may support authorizations for medical services but route pharmacy and certain delegated specialty services to a separate vendor’s portal. Aetna is a familiar example of the delegation pattern: medical requests go through Availity Essentials while pharmacy runs through a pharmacy benefit manager and certain specialty categories are delegated to a specialty benefit manager on many plans.

The rule that follows is short. Before you build the request, confirm three things for the specific payer and plan:

• Does this service actually require prior authorization on this plan? (This is a payer question, and the payer’s code list answers it.)
• Is this payer reachable through Availity for authorizations, not merely for eligibility or claims?
• Is the review delegated to a benefit manager? If it is, that vendor’s portal, not Availity, may be the correct destination for both the submission and any appeal.

Confirm through the payer’s current provider manual or by calling payer provider services, and document the reference number for the call. Availity’s payer list tells you who is connected. Only the payer tells you what it requires.

Working prior authorization across more than one payer? Start with Silna’s complete guide to prior authorization.

How to submit an authorization

Most of the friction in an Availity submission happens before anyone touches the Authorizations & Referrals app. Access is the blocker, and it is an ordinary, fixable one.

Registration, organization, and roles

Availity accounts are organized around an organization, typically your practice or billing entity, identified by tax ID and NPI. Individual users are added under that organization by an administrator, and each user’s visible tools are controlled by the roles assigned to them. A user without the authorization-related role simply will not see the app, and the screen offers no explanation of why.

The recurring failures in this layer:

• The organization was never enrolled with that payer. Many payers require the provider organization to be associated with them inside Availity before their transactions appear. Being registered with Availity is not the same as being connected to a given payer.
• No active administrator. The person who set up the organization left the practice, and nobody can grant roles. Every practice should have at least two administrators; this is the single cheapest preventive step on this page.
• Wrong role. The user has claims access but not authorizations access. The app is missing, not broken.
• Provider data not on file. The rendering or servicing provider was never added to the organization, so they cannot be selected on the request.

What to have ready

Regardless of payer, gather the same core data before starting:

• Member ID exactly as printed on the card, including any alpha prefix
• Patient name and date of birth as they appear on the plan’s record
• Requesting, rendering, and facility NPIs, plus the organization’s tax ID
• CPT / HCPCS code(s) for the requested service, and units or visit counts
• ICD-10 diagnosis code(s) supporting medical necessity
• Requested start date and service setting
• Clinical documentation the payer expects: progress notes, prior conservative treatment, diagnostic results, and the plan of care

Submitting and checking status

Inside Availity Essentials, authorization work lives under the Authorizations & Referrals app. The flow is consistent even though the fields differ by payer: select the organization, select the payer, run an eligibility and benefits check first to confirm the member is active and that you have the right plan, then open the authorization request and complete the payer’s form. The exact fields, the attachment method, and whether an inquiry returns a live decision or a pended status are all determined by the payer, not by Availity.

Two habits pay for themselves: run eligibility before you build the request, because a terminated member or a wrong plan is far cheaper to find in the first minute than in the fifth day; and capture the confirmation number Availity returns on submission, because that number is what makes a later status inquiry or phone call productive.

Status inquiry is where the portal earns its keep. A submitted request typically shows a state such as pending, approved, denied, or a request for additional information, and checking there costs seconds instead of a hold queue. Read the status literally. “Pended for clinical information” means the payer wants records and is waiting on you; it is not a denial, and treating it as one loses days.

When a request fails: Availity vs payer

This is the section to bookmark. When something goes wrong, ask one question first: did the request fail in the channel, or did it fail in the review? The two look similar on a busy afternoon and have nothing in common underneath. A channel failure means the payer never got a decidable request. A review failure means the payer got it, considered it, and said no. Fixing the first is data entry. Fixing the second is clinical advocacy.

The channel failures, and what each one really is.

• Not registered, or not enrolled with the payer. Your organization exists in Availity but was never associated with this payer, so the payer does not appear or its transactions are unavailable. Fix with your administrator and the payer’s enrollment process.
• Payer not enabled for that transaction. The payer is reachable for eligibility and claims but does not accept authorizations through Availity for that plan or region. No amount of retrying changes this. Confirm the correct destination with the payer.
• Wrong payer selected. The most quietly expensive error on the list. Plan names overlap, and a member’s card may name a plan whose authorizations are administered by a different entity. The request goes somewhere real, just not to the entity that will pay the claim, and nobody sends it back with a redirect.
• Bad member data. A transposed member ID, a missing alpha prefix, or a date of birth that does not match the plan’s record. The transaction fails identification and never becomes a request.
• Missing NPI or tax ID, or a provider not on file. The provider cannot be validated or cannot be selected, so the request cannot be built.

A useful test: do you have a determination with a reason and appeal rights? If yes, you are at the payer layer. If all you have is an error, an empty status, or a missing option, you are at the Availity layer, and calling the payer’s medical management line about it will waste an hour. Conversely, if the payer denied on medical necessity, no administrator, role change, or resubmission through the portal will move it. Availity carried the message correctly; the message was no.

Where denials and appeals actually go

A denial is a payer act. The payer’s clinical reviewers applied the payer’s criteria and issued the payer’s decision, and Availity displayed it. It follows, with no exceptions, that the appeal goes to the payer, or to the delegated benefit manager that issued the determination. There is no Availity appeal, no Availity reviewer to reach, and no Availity escalation path for a clinical decision, because Availity never held the decision.

What the portal can do for you after a denial is still useful. It can show you the determination and its status, hold the reference numbers your appeal will cite, and, on some payers, provide the mechanism for sending additional documentation. Availity is your record and your evidence. It is not your counterparty.

The sequence, then:

1. Read the denial notice, not the portal status line. The status field is a summary. The notice states the reason, names the entity that issued it, and states your appeal rights and deadline. If the notice names a benefit manager rather than the health plan, that vendor owns the appeal.

2. Separate administrative from clinical. An administrative denial (wrong code, missing documentation, a data mismatch the payer accepted and then rejected) is usually corrected and resubmitted. Only clinical denials warrant the formal appeal process, and spending appeal rights on an administrative problem is slower than fixing it.

3. Request a peer-to-peer review. For a clinical denial, the treating physician calls the issuing entity’s medical management line and speaks with the reviewing medical director within the window the denial notice specifies. The call is with the payer or its benefit manager. Availity has no medical directors to call.

4. File the formal appeal with the payer. Submit in writing to the address in the denial notice, citing the reference number and addressing the stated denial reason directly. The pathway and deadlines depend on the plan line, commercial, Medicare Advantage, or Medicaid, and each has its own escalation ladder. Our guide to appealing a prior authorization denial walks the sequence in detail.

One phrase to retire from your team’s vocabulary: “Availity denied it.” It is never true, and it sends the next person on your team to the wrong place. The accurate version is “the payer denied it, and I saw the denial in Availity.” That sentence points at the right phone number.

How Silna Reduces Denials

Look at the two-layer split from a distance and a pattern emerges. Channel failures are almost entirely preventable, because everything that causes them is knowable before submission: whether the organization is enrolled with the payer, whether the user has the role, whether the payer accepts authorizations through this channel, whether the member ID and provider identifiers are internally consistent. And a large share of payer-layer denials are preventable too, because the most common one is not a genuine clinical disagreement; it is a documentation gap the practice could have seen, such as an ICD-10 on the authorization form that does not match the ICD-10 in the note.

Silna Health’s Care Readiness Platform automates that pre-submission work end to end: benefits verification, form population, real-time error checking, and submission across the channels a given payer actually uses, whether that is Availity Essentials, a payer’s own portal, or a delegated benefit manager’s. Silna’s Predictive Document Intelligence flags documentation gaps and routing errors before the request leaves the practice, which is the point where they cost minutes instead of weeks. By combining automation with built-in payor communication, Silna cuts pre-visit administrative work by 95%, per Silna Health, 2026.

Silna’s strongest adoption is among ABA therapy, physical therapy, and mental health practices, plus care management for older adults, the practice types that carry high authorization volume across many plans at once and where a single portal never covers the whole payer mix. For teams working Availity every day alongside three other portals, Silna coordinates the full workflow so the first submission is the complete submission, and so the requests that do get denied are denied on the merits rather than on a field. See how it applies to your payer mix at silnahealth.com.

Key terms

Availity Essentials

Availity’s provider-facing portal: one login for eligibility, claims, and, where the payer supports it, authorization submission and status across multiple payers.

Clearinghouse

An intermediary that carries standardized electronic transactions between provider systems and payer systems. It validates format and delivery, not clinical merit.

Authorizations & Referrals

The Availity Essentials app where authorization requests are built and status is checked. Visible only to users whose assigned role includes it.

Organization and roles

Availity’s access model: users belong to an organization (tax ID and NPI), and an administrator grants the roles that determine which apps and payers each user can reach.

Channel failure

A request that never became a valid, decidable submission at the payer: access, enrollment, transaction support, or data problems. No clock is running.

Clinical denial

A determination issued by the payer or its delegated benefit manager after review. Comes with a stated reason and appeal rights, and is appealed to that entity.

Delegated benefit manager

A vendor a payer assigns to review a service category (for example specialty pharmacy or certain imaging). When one issues the decision, both submission and appeal may run through that vendor rather than the plan.

Frequently Asked Questions

This article is general educational information, not medical or insurance advice. Coverage rules, portal capabilities, and clinical criteria vary by payer, plan, and state, so consult a licensed healthcare professional or your plan administrator about your specific situation.

About the author

Jeffrey Morelli

Jeffrey Morelli is the Co-Founder and CEO of Silna Health, the first Care Readiness Platform built to remove the administrative barriers that delay care. Silna automates benefit checks, eligibility, and prior authorizations across 1,000+ payors, and is backed by $27M from Accel and Bain Capital Ventures. Before Silna, Jeff spent a decade in San Francisco building and scaling products for highly regulated industries, including leading go-to-market at Truework (Series C, acquired by Checkr).

Last reviewed: July 13, 2026.