canonical: https://jentic.com/apis/availity.com/availity

# Availity API

Jentic publishes the only available OpenAPI specification for Availity API, keeping it validated and agent-ready. The Availity API exposes US healthcare payer connectivity for revenue-cycle workflows, including payer list lookups, eligibility and benefits checks, and prior-authorization service reviews. Authentication uses OAuth 2.0 client-credentials, and responses follow X12 270/271 and 278 transaction semantics through a JSON facade. The current spec covers four operations across token issuance, payer discovery, and service-review lifecycle.

## For AI agents

Look up healthcare payers, submit prior-authorization service reviews, and track their status against US insurance carriers via Availity's clearinghouse.

## Scope

Does not handle clinical EHR data, claim adjudication payments, or patient scheduling - use for payer discovery and prior-authorization service reviews only.

## Capabilities

- Issue an OAuth 2.0 access token for the Availity clearinghouse via the /v1/token endpoint
- Query the Availity payer list to resolve a payer ID before submitting eligibility or claim transactions
- Submit a prior-authorization service review (X12 278) to a specific payer through /v2/service-reviews
- Retrieve the adjudication status of a previously submitted service review by its identifier
- Map provider, subscriber, and service-line fields into Availity's JSON envelope without writing X12 by hand

## Use cases

### Automated Prior-Authorization Submission

Hospitals and revenue-cycle teams use the Availity service-review endpoint to submit X12 278 prior-authorization requests electronically instead of faxing forms. The Availity API normalises payer-specific fields into a JSON body and returns a tracking ID plus payer response, replacing manual portal entry that typically takes 10-15 minutes per request.

Example prompt: Submit a service review for CPT 70553 to payer ID 60054 with subscriber member ID and service date, then poll /v2/service-reviews/{id} until status is final

### Payer Discovery and Routing

Before sending any 270 or 278 transaction, integrations must resolve the correct Availity payer ID. The /v1/availity-payer-list endpoint returns supported payers with their transaction capabilities, enabling routing logic that picks the right payer code without hard-coding tables that drift over time.

Example prompt: Fetch the Availity payer list, filter for payers supporting service reviews, and return the payer ID matching 'Blue Cross Blue Shield of Texas'

### Service-Review Status Polling

Prior-authorization decisions are rarely instant. Agents poll /v2/service-reviews/{id} to surface approved, denied, or pended outcomes back to schedulers and clinicians, eliminating the need to log into Availity Essentials to chase status. The endpoint returns structured certification numbers and decision reasons.

Example prompt: Retrieve service review {id} every 30 minutes for 24 hours and notify the scheduler when status transitions to approved or denied

### Agent-Driven Eligibility Workflows via Jentic

AI agents handling patient intake call the Availity API through Jentic to verify coverage, identify required prior authorizations, and submit service reviews in a single conversation. Jentic resolves OAuth, payer IDs, and request schemas so agents can focus on the clinical context rather than X12 plumbing.

Example prompt: Given a patient member ID and procedure code, search Jentic for 'submit a service review', load the schema, and execute against Availity, then summarise the response in plain English

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1/token | Issue an OAuth 2.0 access token |
| GET | /v1/availity-payer-list | List supported payers and capabilities |
| POST | /v2/service-reviews | Submit a prior-authorization service review |
| GET | /v2/service-reviews/{id} | Retrieve the status of a service review |

## Key resources

- **Authentication** — OAuth 2.0 client-credentials token endpoint at /v1/token
- **Payers** — Payer-list lookup for routing transactions to the correct carrier
- **Service Reviews** — Submit and retrieve X12 278 prior-authorization service reviews

## Why Jentic

- **Setup:** Wiring Availity by hand means implementing its OAuth2 client-credentials exchange at /v1/token, refreshing the short-lived access token yourself, and shaping X12-style prior-authorization payloads. Through Jentic you install once, import the Availity API from the API Directory, store the client_id and client_secret once, and your agent calls it.
- **Permission scoping:** Availity's service-review calls carry payer, subscriber, and service details in the request body rather than in the URL, so scoping is by operation: limit the agent to the operations it needs, such as listing payers or submitting a service review. You choose which operations it may call, so a review submission is only available if you include it.
- **Credential handling:** Your Availity client_id and client_secret are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'submit a prior authorization' or 'find a payer', and Jentic returns the matching Availity service-review operation with its input schema so the agent can populate payer, subscriber, and service-line fields without reading X12 documentation.

## Related APIs

- **Stripe** — Pair Availity prior-auth checks with Stripe for patient-responsibility billing once coverage is confirmed.
- **Plaid** — Use Plaid to verify patient bank accounts for ACH co-pay collection alongside Availity eligibility checks.
- **Avalara AvaTax** — Avalara handles tax calculation on healthcare-adjacent retail or DME transactions where Availity handles payer connectivity.

## FAQ

### Why is there no official OpenAPI spec for Availity API?

Availity does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Availity API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Availity API use?

The Availity API uses OAuth 2.0 client-credentials. Your agent posts client_id and client_secret to /v1/token and receives a bearer access token. Through Jentic, your client credentials live in your Jentic One instance and are exchanged for short-lived tokens automatically - the agent never sees the raw secret.

### Can I submit prior authorizations with the Availity API?

Yes. POST /v2/service-reviews submits an X12 278 prior-authorization request to a payer, and GET /v2/service-reviews/{id} retrieves the decision. The current spec covers submission and retrieval - coverage of attachment uploads and inquiry transactions varies by payer.

### What are the rate limits for the Availity API?

Availity does not publish a single global rate limit; throttling is governed per-application and per-payer in their developer portal. Plan for at least one-second spacing between service-review submissions to the same payer and back off on HTTP 429.

### How do I look up a payer ID through Jentic?

Search Jentic for 'list Availity payers', load the schema for GET /v1/availity-payer-list, and execute. The response contains payer names, IDs, and the transaction types each payer supports so the agent can pick the right code before submitting.

### Is the Availity API free to use?

Availity offers free developer accounts for testing, but production access typically requires a sponsoring provider or trading-partner agreement and may carry transaction fees through your contract with Availity.

### Can I limit what my agent is allowed to do with the Availity API?

Yes. Because you run Jentic One yourself, you decide which Availity operations your agent may call, and it can only invoke the ones you include. You can allow a read-only path such as listing payers with GET /v1/availity-payer-list and checking status with GET /v2/service-reviews/{id} while withholding POST /v2/service-reviews, so the agent cannot submit a prior-authorization review unless you grant that operation. Since payer, subscriber, and service details travel in the request body rather than the URL, scoping is enforced at the operation level, and your stored client credentials are injected only for the calls you permit.