Availity API

Name: Availity API
Brand: Availity API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentHealthcareEhr Emroauth24 EndpointsREST

For Agents

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

Install Jentic One Beta

Connect the Availity API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Availity API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Availity API.

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

GET STARTED

Start building with Availity API

Explore with Jentic

View OpenAPI Document

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.

Use Cases

Patterns agents use Availity API for, with concrete tasks.

★ 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.

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.

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.

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.

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

4 endpoints — jentic publishes the only available openapi specification for availity api, keeping it validated and agent-ready.

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

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Availity client_id and client_secret are stored encrypted in the Jentic vault. Jentic exchanges them for short-lived OAuth access tokens at /v1/token on the agent's behalf — raw secrets never enter the agent's context.

Intent-based discovery

Agents search by intent (e.g., 'submit a prior authorization') and Jentic returns the matching Availity service-review operation with its full request schema, so the agent can populate payer, subscriber, and service-line fields without reading X12 documentation.

Time to first call

Direct Availity integration: 1-2 weeks for OAuth, payer-list caching, and X12 278 field mapping. Through Jentic: under 1 hour — search, load schema, execute.

FAQs

Specific to using Availity API through Jentic.

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 at https://app.jentic.com/sign-up.

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 the Jentic vault 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.

Availity API

Connect the Availity API to your agent

Capabilities

Start building with Availity API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs