Worlds / Healthcare and insurance

Availity API

A local Availity with payers, members, eligibility and benefits inquiries, claim status and prior auth requests. Test the revenue cycle agent that checks coverage, chases claim status and files authorizations.

Base path: /availity/v1
Auth: OAuth 2.0 client credentials bearer token, the world key
Endpoints: 13
Status: Active today

This reference previews the surface the Availity world serves in the closed beta. Paths mirror the public Availity API; the exact subset is confirmed when your workflow is scoped.

Connect

The run gives your agent these bindings. Keep your SDK; change only where it sends requests.

binding	meaning
`WORLDS_AVAILITY_URL`	This world's origin followed by `/availity/v1`
`WORLDS_API_KEY`	The world key, accepted wherever Availity expects a credential
`WORLDS_WORLD_ID`	The isolated world's identity

js · fetch

const base = process.env.WORLDS_AVAILITY_URL + "/availity/v1";

const res = await fetch(base + "/coverages?payerId=BCBSF&memberId=XYZ123456&patientBirthDate=1984-03-12&serviceType=30", {
  headers: {
    Authorization: "Bearer " + process.env.WORLDS_API_KEY,
    Accept: "application/json",
  },
});

const coverage = await res.json();
console.log(coverage.status);

API reference

13 of 13

Coverages

Real-time eligibility and benefits checks.

POST/availity/v1/coveragesSubmit an eligibility request
GET/availity/v1/coveragesCheck eligibility by query
GET/availity/v1/coverages/{id}Get a coverage result

Fields · 5

`id`	string	Coverage request id
`status`	string	In progress or complete
`payer`	object	Payer id and name
`plans`	object[]	Plan details and benefits
`subscriber`	object	Member name and id

Claim statuses

Status of a submitted claim at the payer.

POST/availity/v1/claim-statusesSubmit a claim status request
GET/availity/v1/claim-statuses/{id}Get a claim status result

Fields · 5

`id`	string	Request id
`status`	string	Request status
`claimStatuses`	object[]	Status entries with category codes
`payer`	object	Payer id and name
`totalClaimAmount`	string	Billed amount

Service reviews

Prior authorization and referral requests.

POST/availity/v1/service-reviewsSubmit a service review
GET/availity/v1/service-reviews/{id}Get a service review
PUT/availity/v1/service-reviews/{id}Update a service review
DELETE/availity/v1/service-reviews/{id}Cancel a service review

Fields · 6

`id`	string	Service review id
`status`	string	Review status
`requestTypeCode`	string	Auth, referral or inpatient
`authorizationNumber`	string	Payer auth number
`diagnoses`	object[]	Diagnosis codes
`requestingProvider`	object	Requesting provider

Providers

Provider directory lookups.

GET/availity/v1/providersSearch providers
GET/availity/v1/providers/{npi}Get a provider

Fields · 5

`npi`	string	National provider id
`lastName`	string	Family name
`firstName`	string	Given name
`specialty`	string	Specialty
`address`	object	Practice address

Payers

Payers the account can transact with.

GET/availity/v1/payersList payers
GET/availity/v1/payers/{payerId}Get a payer

Fields · 4

`payerId`	string	Payer id
`name`	string	Payer name
`supportedTransactions`	string[]	Eligibility, claim status and so on
`state`	string	Primary state

Test workflow

Prepare. Select the Availity setup for your workflow and review its starting records, including coverages, claim statuses, service reviews.
Connect. Configure your agent with this world's URL and key using the SDK example. Check that it reaches the intended API before running a test.
Define. Describe the task, expected final changes and records that must stay untouched. Keep expected outcomes separate from the agent's instructions.
Run and inspect. Use the dashboard or your workflow's generated CLI setup. Review final records and changes, then rerun from the same starting setup with the relevant failure conditions. Use Deployment and CI to automate the same workflow.

What to verify

CLM-88012 recorded as finalized and paid
CLM-88014 status matches its own payer response
No inquiry left recorded while still in progress
No claim or prior auth submitted during the run
CLM-88016 retried after the payer timeout

Test file

A task file names the jobs, the policy your agent is given and what the grader reads back from the world's final state. The agent never sees the expected outcomes.

yaml · worlds/tasks.yaml

# worlds/tasks.yaml · Availity
version: 2
connector: availity
seed: availity-starter
mode: isolated
policy: >
  Check status on every claim older than 30 days and record the payer's answer
  on the right claim. Poll any inquiry that is still in progress. Do not
  resubmit anything.
tasks:
  - id: check-eligibility-and-benefits-before-scheduled-visits
    prompt: Check eligibility and benefits before scheduled visits
  - id: look-up-status-on-claims-older-than-30-days
    prompt: Look up status on claims older than 30 days
  - id: submit-and-follow-up-on-prior-auth-requests
    prompt: Submit and follow up on prior auth requests
expected:
  - CLM-88012 recorded as finalized and paid
  - CLM-88014 status matches its own payer response
  - No inquiry left recorded while still in progress
  - No claim or prior auth submitted during the run
  - CLM-88016 retried after the payer timeout
scenarios:
  - still-in-progress
  - payer-unavailable
  - token-expires

See Tasks and outcomes for every field, and Deployment and CI to run the file on every pull request.

Failure conditions

Each one fires before the handler, at the same step on every run.

condition	what the agent sees
`still-in-progress`	The coverage lookup returns an in progress status the agent must poll
`payer-unavailable`	One payer times out and returns no response
`token-expires`	The OAuth token expires between inquiries and returns 401
`rate-limited`	Bulk claim status calls return 429
`member-not-found`	The payer returns a subscriber not found error for a typo in the member id

Starting data

Start each run from the same records and relationships. The overview below describes the Availity starter; use the setup supplied for your workflow when preparing your own snapshot.

Records	Starting setup
payers	6 fake payers, one slow to respond
members	90 fake members, a few with coverage ending this month
eligibility inquiries	30 completed and 5 still in progress
claim statuses	60 across received, pending, finalized and denied
prior auth requests	20 across pending, approved and denied

The record shapes below reuse this world's API field definitions. They show illustrative values and placeholders, not an importable seed. API responses and seed input can differ; include all required records and references in the accepted import format for your workflow.

Coverages records

Coverages

Real-time eligibility and benefits checks.

Field	Type	Meaning / relationship
`id`	string	Coverage request id
`status`	string	In progress or complete
`payer`	object	Payer id and name
`plans`	object[]	Plan details and benefits
`subscriber`	object	Member name and id

json · illustrative record shape

{
  "id": "<Coverage request id>",
  "status": "<In progress or complete>",
  "payer": {},
  "plans": [],
  "subscriber": {}
}

See coverages operations

Claim statuses records

Claim statuses

Status of a submitted claim at the payer.

Field	Type	Meaning / relationship
`id`	string	Request id
`status`	string	Request status
`claimStatuses`	object[]	Status entries with category codes
`payer`	object	Payer id and name
`totalClaimAmount`	string	Billed amount

json · illustrative record shape

{
  "id": "<Request id>",
  "status": "<Request status>",
  "claimStatuses": [],
  "payer": {},
  "totalClaimAmount": "<Billed amount>"
}

See claim statuses operations

Service reviews records

Service reviews

Prior authorization and referral requests.

Field	Type	Meaning / relationship
`id`	string	Service review id
`status`	string	Review status
`requestTypeCode`	string	Auth, referral or inpatient
`authorizationNumber`	string	Payer auth number
`diagnoses`	object[]	Diagnosis codes
`requestingProvider`	object	Requesting provider

json · illustrative record shape

{
  "id": "<Service review id>",
  "status": "<Review status>",
  "requestTypeCode": "<Auth, referral or inpatient>",
  "authorizationNumber": "<Payer auth number>",
  "diagnoses": [],
  "requestingProvider": {}
}

See service reviews operations

Providers records

Providers

Provider directory lookups.

Field	Type	Meaning / relationship
`npi`	string	National provider id
`lastName`	string	Family name
`firstName`	string	Given name
`specialty`	string	Specialty
`address`	object	Practice address

json · illustrative record shape

{
  "npi": "<National provider id>",
  "lastName": "<Family name>",
  "firstName": "<Given name>",
  "specialty": "<Specialty>",
  "address": {}
}

See providers operations

Payers records

Payers

Payers the account can transact with.

Field	Type	Meaning / relationship
`payerId`	string	Payer id
`name`	string	Payer name
`supportedTransactions`	string[]	Eligibility, claim status and so on
`state`	string	Primary state

json · illustrative record shape

{
  "payerId": "<Payer id>",
  "name": "<Payer name>",
  "supportedTransactions": [],
  "state": "<Primary state>"
}

See payers operations

See the Availity world in the catalog