Availity

Availity is the clearinghouse. One product subscription covers both APIs this platform uses.

#Which product

Healthcare HIPAA Transactions

Plus its Demo tier for the sandbox. Both APIs declare the same scope family, so one subscription entitles both.

API	Base path	Used for
Service Reviews	`/v2/service-reviews`	X12 278 prior authorization
Coverages	`/v1/coverages`	270/271 eligibility, including the authorization indicator
Token	`/v1/token`	OAuth2 client credentials

Two notes on the catalogue. Coverages also accepts a narrower rcm-coverages scope, but taking that instead means a second subscription for no additional reach, since Service Reviews needs the main product anyway. And AWS Availity Payer List is redundant - the payer list is already inside the main product.

#Authentication

bash

curl -X POST https://api.availity.com/v1/token \
  -d grant_type=client_credentials \
  -d client_id=$AVAILITY_CLIENT_ID \
  -d client_secret=$AVAILITY_CLIENT_SECRET \
  -d scope=healthcare-hipaa-transactions

Tokens live 300 seconds and there is no refresh grant

A 401 mid-session is almost always the expiry, not bad credentials. Treating it as an auth failure sends an engineer to check secrets that are fine. The adapters re-mint with a ten-second margin.

#The base paths differ

Service Reviews is /v2. Coverages is /v1. They are the same product with different versions, and assuming one from the other produces a 404 that looks like an entitlement problem.

#Errors are not RFC 9457

json

{
  "statusCode": 400, "reasonCode": 0,
  "userMessage": "...", "developerMessage": "...",
  "errors": [{ "code": 0, "errorMessage": "..." }]
}

A client written against problem+json will read every field as undefined and report an empty error, which is worse than reporting the raw body.

#Rate limiting is bare

A 429 carries no Retry-After. Backoff is blind against the plan ceiling, so it has to be conservative rather than reactive.