Availity API Guide

Submitted by katieaugustus on Mon, 01/22/2024 - 22:19

Introduction

Scope

The purpose of this Availity API Guide is to communicate product overviews, documentation, and additional information about using Availity's REST APIs to build a custom healthcare data exchange application.

Overview

Availity, LLC, is a market leader in secure healthcare data exchange. The Availity® Health Information Network is operationally HIPAA compliant, accepting and processing in a secure environment all American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12N standard transactions mandated by the Health Insurance Portability and Accountability Act (HIPAA).

Availity's real-time REST APIs allow developers to write compelling healthcare applications with connectivity to every health plan nationwide and access to more than 8.8 million daily healthcare transactions. Your application can reach more than a million providers with robust tools that simplify transactions and translate complex data responses.

Benefits

Building your application with Availity's REST APIs offers the following benefits:

  • Predictable, resource-oriented URLs that return JSON and XML representations, including errors using HTTP response codes.
  • Trusted security through OAuth2, SHA256, or MD5 over HTTPS.
  • Standard responses to HIPAA inquiries for eligibility, claim status, claim predeterminations, and other transactions.
  • Web calls for real-time responses.
  • Comprehensive documentation, including authentication and coding examples with sample responses.
  • Ability to register online and get an API key to get started right away.

Supported EDI transactions

The table displays information about the healthcare electronic data interchange (EDI), also called HIPAA, transactions Availity supports.

 
Availity-supported HIPAA transactions
FormatVersion supportedTransaction type
ASC X12N 837005010X223A2Institutional claims
ASC X12N 837005010X222A1Professional claims
ASC X12N 837005010X224A2Dental claims
ASC X12N 270 and 271005010X279A1Eligibility and benefits inquiry and response
ASC X12N 275005010X210Additional information to support a claim or encounter (also known as medical attachments)
ASC X12N 276 and 277005010X212Claim status request and response
ASC X12N 278005010X217Services request (authorization and referral) for review/response
ASC X12N 278005010X216Services review notification and acknowledgement
ASC X12N 835005010X221A1Claim payment/advice (also known as electronic remittance advice)

Rules for format, content, and data element values for each transaction are listed in the individual ASC X12 Technical Report Type 3 (TR3) implementation guides. For a cost, you can obtain TR3s from the publisher, Washington Publishing Company (WPC) (http://www.wpc-edi.com/). WPC offers implementation guides for each transaction type in a regular version and a combined version, which contains the addenda.

Notes on documentation in this guide

cURL

Availity uses cURL for all samples in this guide so you can try them. You can download cURL software if needed. Be sure to include your API key and specific IDs for calls.

Sample requests

The sample requests in this guide are examples only and not runnable as is. Substitute all call-specific parameters (such as API keys, access tokens, and ID numbers) with your own values.

Date/time format

Availity APIs use the ISO 8601 format:

"createdDate": "2014-06-16T18:38:12.000+0000"

Product overview

Availity's web service REST API products offer predictable, resource-oriented URLs and use HTTP response codes to indicate success and failure conditions. These APIs all return JSON and XML representations, including errors, while some have the ability to return CSV, PDF, PNG, and XLS representations.

Refer to each API's reference section for documentation of endpoints, request parameters, sample requests and responses, and response definitions.

Note: Sample requests are examples only and not runnable as is, so be sure to substitute all call-specific parameters (API Keys, access tokens, and response IDs) with your own values.

Healthcare HIPAA Transactions

The APIs included in Availity's HIPAA Transactions product allow your application to exchange HIPAA-compliant X12N transactions. The Availity Partner OAuth2 Provider 1.0.0 API is described in the Authentication section.

Availity Payer List 1.0.4

This API allows you to query the list of available payers and transactions based on your Availity contract.

Configurations 1.0.0

Availity's Configurations API can help save weeks of development time by providing details for each payer Availity supports, as well as the required fields for a specific payer, required field combinations, validation patterns that can be used by your frontend applications, code/values for populating selection groups, and more.

If you've ever tried to support access to multiple health plans in your application, you know how difficult this can be. Although standards such as ASC X12N transactions and HL7 exist, many health plans support these standards at different levels. Traditionally, this would leave the burden on the developer to figure out how to normalize this information across the range of health plans the application must support. Instead, by using the Configurations resource to build your application, you can ensure you always have the most current data and validation requirements for each health plan.

Coverages 1.0.0

Supporting the ASC X12N 270 and 271 transactions (Healthcare Eligibility Benefit Inquiry and Response), this API allows you to find and manage a member's coverage information.

Service Reviews 2.0.0

Find, create, and manage authorizations to perform a healthcare service or refer a patient to another provider with this API, which enables the ASC X12N 278 transaction (Health Care Services Review – Request for Review and Response).

Claim Statuses 1.0.0

This API enables the standard ASC X12N 276 and 277 transactions (Health Care Claim Status Request and Response), which allow you to find, create, and manage claim status information.

Care Cost Estimator – Professional and Care Cost Estimator – Institutional

A care cost estimator (CCE), also known as a predetermination, is a claim request for payment that a healthcare provider submits to a health plan before it has provided a service or items to a member. Claim predeterminations allow patients to learn early whether a particular healthcare service is covered by their health plan. Your application can use the Professional or Institutional Care Cost Estimator API to submit a claim predetermination and to find and manage previous claim predetermination requests.

Availity offers two Care Cost Estimator APIs: Professional (for physicians, suppliers, and other non-institutional providers) and Institutional (for hospitals, skilled nursing facilities, and other institutions).

Add-On API products

Enhanced Claim Status (claim-status 1.0.0 )

Enhanced Claim Status supports both the HIPAA 276/277 transaction as well as several proprietary requests to gather additional claim status information. With Enhanced Claim Status, health plans can add additional summary and detail search options and customize the X12N 277 response with additional information fields, including remark codes and descriptions, amount fields (deductible, discount, copay, co-insurance, patient responsibility), group number, line of business, provider type (rendering, billing), and many more.

Service Reviews Add-On APIs

Availity offers two add-on APIs that work in conjunction with the Service Reviews API to enhance the ASC X12N 278 transaction:

  • IsAuthRequired – Allows providers to determine whether a payer requires an authorization for a service before completing the authorization request.

  • Auth Attachments – enables third-party submitters to add attachments to an existing authorization.

Eligibility & Benefits Value-Add APIs

Availity offers two APIs that add functionality to the eligibility and benefits (ASC X12 270/271) transaction:

  • Care Reminders: a multi-payer API that supports the real-time request and retrieval of care reminders for use within an eligibility and benefits transaction.

  • Member ID Card: a multi-payer API that supports the real-time request and retrieval of member ID cards during an eligibility and benefits inquiry. The service supports both PDF and PNG documents.

Authentication

Availity REST APIs support the application-only authentication method, which is based on the Client Credentials Grant flow of the OAuth 2.0 spec. All Availity REST APIs support OAuth 2.0 over HTTPS for authentication, including requests to demo resources.

To make a REST API request to Availity, you must first follow the steps listed in the Getting Started section. After you have created your API account, registered your application, and subscribed to an API product, you must take two steps to make an initial API request:

  1. Get an OAuth 2.0 access token.

    Make a POST request to the Availity Partner OAuth2 Provider 1.0.0 API (endpoint: POST/v1/token). This request returns a response that contains an access_token, token_type, and expiration_time. The access token is only valid for five minutes:

    curl -i -X "POST" "https://api.availity.com/availity/v1/token" \
      -d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=hipaa"
    
    ->
    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: application/json
    Cache-Control: private, no-store, no-cache, must-revalidate
    Pragma: no-cache
    
    { "token_type":"bearer", 
    "access_token":
    "AAEkZGI1ZjRhYzgtYWViNy00NmRmLWE0YjYtND5NTliZDI0NTc2kPwma8ezU6mkghUoomSLMUbB8LM
    Pc4NJFNkEyrrmFMZabZ67DHXL3gaCr01
    _mln8-qLDQWne-8stwXOpb2dObXP3SAt8yn1LDQehlNw_KTcZf1H1-FyAFyM5Nh4g0zNs9ATtj2l-H98
    FzXl9MoBA", "expires_in":300, "scope":"hipaa" }
    Note: The request body parameters are case sensitive. Make sure grant_type=client_credentials, client_id=your_client_id, client_secret=your_client_secret, and scope=hipaa match exactly as they are shown.
  2. Call the API with the access token.

    Use the access token from Step #1 to make a request to an Availity REST API. The example below illustrates making a request to the Coverages resource and includes the Availity demo endpoints.

     curl -i -H "Authorization: Bearer $ACCESS_TOKEN" -X GET "https://api.availity.com/availity/v1/coverages" 
    ->
    {
      "totalCount": 5,
      "count": 5,
      "offset": 0,
      "limit": 50,
      "links": {
        "self": {
          "href": "https://api.availity.com/availity/v1/coverages"
        }
      },
      "coverages": [
        {
          "links": {
            "self": {
              "href": "https://api.availity.com/availity/v1/coverages/0001234821666577173234942038175340242587013739108497709963594997"
            }
          },
          "id": "0001234821666577173234942038175340242587013739108497709963594997",
          "customerId": "4321",
          "controlNumber": "9876543",
          "status": "Complete",
          "statusCode": "4",
          "createdDate": "2017-06-15T16:31:07.000+0000",
          "updatedDate": "2017-06-15T16:31:07.000+0000",
          "expirationDate": "2017-06-16T16:31:07.000+0000",
          "asOfDate": "2017-06-15T04:00:00.000+0000",
          "requestedServiceType": [
            {
              "code": "30",
              "value": "Health Benefit Plan Coverage"
            }
          ],
          "subscriber": {
            "firstName": "ZENA",
            "lastName": "MARDIN",
            "memberId": "H87654321",
            "gender": "Female",
            "genderCode": "F",
            "birthDate": "1942-09-15T04:00:00.000+0000"
          },
          "patient": {
            "firstName": "ZENA",
            "lastName": "MARDIN",
            "subscriberRelationship": "Self",
            "subscriberRelationshipCode": "18",
            "gender": "Female",
            "genderCode": "F",
            "birthDate": "1942-09-15T04:00:00.000+0000"
          },
          "payer": {
            "name": "HUMANA",
            "payerId": "HUMANA"
          },
          "requestingProvider": {
            "npi": "1234567893",
            "taxId": "123123123"
          },
          "plans": [
            {
              "status": "Active Coverage",
              "statusCode": "1",
              "groupNumber": "P1234567"
            }
          ]
        }
      ]
    }
Note: Client IDs are case sensitive.

Security and cross-site scripting prevention

One of the most commonly exploited web security vulnerabilities is cross-site scripting (XSS). This type of attack tricks a company into serving malicious JavaScript to users' browsers. This is possible because browsers do not distinguish between text to show the user and scripts to execute.

Availity continually works to keep both your data and ours as secure as possible. We employ two methods to help prevent XSS attacks:

  1. Input validation and sanitization
  2. Encoding resources specifically for their intended use and context

Input validation and sanitization

Availity has implemented whitelist rules for data validation that are carefully designed to provide protection even against future vulnerabilities introduced by browser changes. If you send a request to an API that contains characters that we've determined to be unsafe, you'll receive an HTTP 400 response with an inbound injection error message. You must fix the data and resubmit your request. The best way to avoid receiving this error is to ensure that you use proper input validation and sanitization on your side before calling an API.

Response resource encoding

Different encoders exist for each given context; i.e., an HTML body string encode isn't the same as a JavaScript string encode. This is where problems can arise, as XSS attacks also vary from context to context. If encoding isn't done properly for the context in which you're displaying the data, an attack can slip through.

Availity does not provide response resource encoding for an API by default. To take advantage of encoding, you must opt in by sending an X-Response-Encoding-Context request header with one of the following values:

  • HTML: for use in HTML entities

  • HTML_ATTRIBUTE: for use in HTML attribute values

  • CSS: for use in stylesheets and style tags

  • URL: for use in a URL

  • JAVA_SCRIPT: for use in JavaScript data values

  • XML: for use in XML entities

  • XML_ATTRIBUTE: for use in XML attribute values

Availity recommends that you use the appropriate response encoding context if you will be displaying API resources directly in your application.

Encoding examples

Below is an example request to the Configurations API showing a partial resource returned using the HTML encoding context. The providerNpi.errorMessage object appears because the message contents that contain () characters are escaped for use in HTML.

curl -X "GET" "https://api.availity.com/availity/v1/configurations?type=270&payerId=700" -H "Authorization: Bearer abc12345" -H "X-Response-Encoding-Context : HTML"
configurations[0].providerNpi.errorMessage = "Enter a valid National Provider Identifier (NPI) containing 10 numeric digits and beginning with a 1, 2, 3, or 4."

Collection resources

If you need to interact with multiple resources at once, you must do so with a collection resource. A collection is a first-class resource that contains additional resources and supports pagination, sorting, and searching.

 
Collection resource response fields
FieldDescriptionMinMaxDefaultType
linksSet of resource URIs.---Object
offsetThe zero-based starting index in the collection of the first item to return.0-0Integer
limitThe maximum number of collection items to return for a single request.15050Integer
countThe number of items returned.0--Integer
totalCountTotal number of items available that match the parameters specified.0--Integer
resourcesAn array containing the current page of resources. The attribute name is the plural name of the resource type, such as coverages. The size of the array can be less than the requested limit when, for example, the limit requested is greater than the maximum allowed or the response returned less than the limit amount.0--Array

Pagination

When a collection resource contains a large number of resource instances, all of them may not be included in a single response. Instead, pagination breaks up the results into one or more pages of data. You can request additional pages as separate requests. Here's an example of a collection resource partial response:

{
  "totalCount": 19,
  "count": 5,
  "offset": 0,
  "limit": 5,
  "links": {
    "last": {
      "href": "https://api.availity.com/availity/v1/coverages?limit=5&offset=14"
    },
    "next": {
      "href": "https://api.availity.com/availity/v1/coverages?limit=5&offset=5"
    },
    "self": {
      "href": "https://api.availity.com/availity/v1/coverages?limit=5"
    }
  },
  "coverages": [
    {
      "customerId": "1194",
      "batchId": "14029438773180168889579000001660",
      "controlNumber": "1-1020",
      "status": "Communication Error",
      "statusCode": "14",
      "createdDate": "2017-07-16T18:38:12.000+0000",
      "updatedDate": "2017-07-16T18:38:12.000+0000",
      "expirationDate": "2017-07-16T19:07:23.000+0000",
      "asOfDate": "2017-02-03T05:00:00.000+0000"
    },
    {
        ...
    }
  ]
}

Query parameters

Availity APIs use cursor-based pagination with two optional query parameters:

  • Offset: the zero-based starting index in the collection of the first item to return. Default is 0.

  • Limit: the maximum number of collection items to return for a single request. Minimum value is 1; maximum value is 50.

Link relations

The links field contains link relations depending on the page and number of resources returned. When a link relation is not available, you receive a null value when trying to access it.

 
Link relationDefinitionHREF
selfURL used to retrieve the collection resources.https://api.availity.com/availity/v1/coverages?offset=50&limit=50"
firstURL to retrieve the first page of resources.https://api.availity.com/availity/v1/coverages?offset=0&limit=50"
lastURL to retrieve the last page of resources.https://api.availity.com/availity/v1/coverages?offset=251&limit=50"
nextURL to retrieve the next page of resources.https://api.availity.com/availity/v1/coverages?offset=100&limit=50"
prevURL to retrieve the previous page of resources.https://api.availity.com/availity/v1/coverages?offset=0&limit=50"

HTTP status and error codes

When REST API responses contain an error or warning, they return a response body with extended error information. Conventional HTTP status codes indicate the success or failure of an API request. In general, codes in the 2XX range indicate success; codes in the 4XX range indicate missing required parameters or authentication/authorization failures; and codes in the 5XX range indicate an error within Availity's or downstream servers. Here's a sample error response:

{
    "statusCode": 404,
    "userMessage": "The coverage you specified cannot be found.",
    "developerMessage": "The specified coverage cannot be found. 
      If you accessed this url via a stale href reference,
      it's possible the coverage object has expired in our 
      system, you should acquire the members Coverage Collection 
      Resource again to obtain the current list of coverages.",
    "url": "https://api.availity.com/availity/v1/documentation/coverages",
    "errors": [
        {
            "code": 545,
            "errorMessage": "Some other extended error occurred"
        },
        {
            "code": 615,
            "errorMessage": "Some other extended error occurred"
        }
    ]
}

The following table defines general HTTP status codes for various API requests.

 
HTTP status code definitions
CodeStatusVerbDefinition
200OKGET, PUTYou successfully retrieved or updated an existing resource.
200OKGET by IDThe operation was successful and returns 0 or more resources. The metadata count property in the response body contains the number of resources returned.
200OKPATCHYou successfully updated field(s) in an existing resource.
201CreatedPOSTYou successfully created a new resource.
202AcceptedGET, POST, PUT, DELETE, PATCHThe request has been accepted for processing, but the processing has not been completed. The location header contains the URI to monitor for status updates.
204No contentDELETEThe service fulfilled the request, which may have removed a resource from the server cache, server database, or external resource. The API client can consider the resource no longer available.
303See otherGETThe response to the request can be found under a different URI provided in the location header and should be retrieved using a GET method on the URI.
400Bad RequestGET by IDThe resource did not understand the request due to malformed query parameters.
400Bad RequestPOSTThe resource did not understand the request due to malformed syntax.
400Bad RequestPUTThe resource did not understand the request due to malformed syntax.
401UnauthorizedGET, POST, PUT, DELETE, PATCHThe API client is not authorized to make this request. The request requires user authentication.
403ForbiddenGET, POST, PUT, DELETE, PATCHThe server understood the request, but is refusing to fulfill it. This may be temporary or permanent, depending on the use case.
404Not FoundGET, PUT, DELETE, PATCHThe service has not found anything matching the request URI. There is no indication whether the condition is temporary or permanent.
405Method Not FoundGET, POST, PUT, DELETE, PATCHThe method specified in the request-line is not allowed for the resource identified by the request-URI.
406Not AcceptableGET, POST, PUT, DELETE, PATCHThe resource identified in the request is only capable of generating response entities that have unacceptable content characteristics according to the accept headers sent in the request.
409ConflictPOST, PUT, DELETE, PATCHThe service could not complete the request due to a conflict with the current state of the resource.
410GoneGET, PUT, DELETE, PATCHThe requested resource is no longer available and has no known forwarding URI. This condition is permanent.
415Unsupported Media TypeGET, POST, PUT, PATCH, DELETEThe server refuses to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
422Unprocessable EntityPOST, PUT, PATCH, DELETEThe JSON/XML request entity is properly formed and the media type is supported; however, validation failed or the request entity is a different type or version than the service supports.
429Too Many RequestsGET, POST, PUT, PATCH, DELETEThe transaction rate limit has been exceeded. Refer to the FAQ section for more information on this code.
500Internal Server ErrorGET, POST, PUT, PATCH, DELETEThe service encountered an unexpected condition that prevented it from fulfilling the request.

The following table defines the attributes that may be returned in an error response:

 
Error response attributes
AttributeDefinitionType
statusCodeHTTP status codeInteger
reasonCodeInternal error code (currently not used)Integer
userMessageError message appropriate for displaying to end userString
developerMessageA more detailed error message appropriate for a developerString
urlURL where more information on the error can be foundString
errorsA collection of extended error messagesArray
errors.codeService-specific error codeInteger
errors.errorMessageService-specific error message for error codeString

Refer to the reference documentation for individual APIs for information on API-specific status and error codes.

Demo services

Availity offers a trial package that allows you to begin exploring our APIs without completing a formal application process. Using demo data (without personal health information [PHI]), you'll get up to speed quickly, at no cost to you.

You can choose which demo response you want by sending a header with X-Api-Mock-Scenario-ID in your request. The value is the ID of the response scenario you want. For demo response confirmation, inspect the response header for X-Api-Mock-Response: true. You can find supported response scenarios in each applicable API's reference section.

Note: Not all Availity APIs support demo response scenarios.
Note: The Demo environment returns canned responses; therefore, the data you receive does not change based on the request.

Refer to the Getting Started section for instructions on subscribing to the Demo environment.

Availity API workflow

Most of Availity's REST APIs use the following workflow to obtain a complete response from the payer:

1. Initial Request 2. Initial Response 3. Polling Request 4. Polling Response. Repeat steps 3 and 4 until you receive a final status code.
  1. The initial request is the intial API request to the API endpoint containing all the parameter information needed to retrieve the data.

  2. The initial response is the response to your initial request, which contains three key pieces of information:

    1. Response ID – the unique ID for your request, which is used as the "key" to any follow-up requests and can be found in the location header with the full URL and in the response body.

    2. Status – a description of the status of your API request.

    3. Status code – the alphanumeric status code for your API request. (Note: This is NOT the same as the status code used in the claim-related APIs).

      Sample initial response:

      {
      "totalCount": 1,
      "count": 1,
      "offset": 0,
      "limit": 1,
      "links": {
      "self": {
      "href": "https://api.availity.com/availity/v1/coverages?payerId=101&providerNpi=x..."
      }
      },
      "coverages": [
      {
      "links": {
      "self": {
      "href": "https://api.availity.com/availity/v1/coverages/7276849100383928590"
      }
      },
      "id": "7276849100383928590",
      "customerId": "22032",
      "status": "In Progress",
      "statusCode": "0",
      "createdDate": "2021-10-19T15:01:53.000+0000",

      The status code and description values vary slightly by API and are documented in the reference documentation sections for each API in this guide. The two most common status codes are 0 - In Process, for which you need to perform a follow-up (polling) request to get the complete response from the payer; and 4 - Complete, which indicates a complete response from the payer. Any other error codes indicate some form of error, and you should examine the response body for details.

  3. The polling request uses the response ID from Step 2 in the URL of the API endpoint to "poll" whether the API has received the complete information from the payer. Example (with the response ID underlined):

    api.availity.com/availity/v1/coverages/7276849100383928590

  4. Polling response: check the status code contained in the response from the polling request. If it indicates the response is still in process, repeat the polling request after a brief pause (e.g., 2 seconds).

    Sample polling response:

    "id": "7276849100383928590",
    "customerId": "22032",
    "controlNumber": "38729508730",
    "status": "Complete",
    "statusCode": "4",
    "createdDate": "2021-10-19T15:01:53.000+0000",
    "updatedDate": "2021-10-19T15:01:53.000+0000",
    "expirationDate": "2021-10-20T15:01:53.000+0000",
    "asOfDate": "2021-01-01T05:00:00.000+0000",      

Repeat steps 3 and 4 until you receive a final status code.

Contact information

Availity Client Services

For questions, assistance, and support, log in to Availity Essentials and submit an online support ticket (24/7) by navigating to Help & Training > Availity Support on Availity Essentials. Or contact an Availity Client Services representative at 800-282-4548 (800-AVAILITY).

Days of operation: Monday through Friday

 
Eastern Time ZoneCentral Time ZoneMountain Time ZonePacific Time Zone
8:00 a.m. to 8:00 p.m.7:00 a.m. to 7:00 p.m.6:00 a.m. to 6:00 p.m.5:00 a.m. to 5:00 p.m.

Frequently asked questions

Getting started

Why do I need to create an app?

An app, or application, is the link between your organization and Availity's authentication system and API subscription plans.

When you create an application, you receive both a client ID and client secret. (Make note of both items, but especially the client secret, as this is the only time you will see it.) You must supply the client ID and client secret when you call our OAuth 2 authentication API. An authentication (bearer) token will then be returned to you which is valid for 5 minutes. Use that token to make subsequent calls to our API endpoints. See the Authentication section of the Availity API Guide for more information.

What are Availity's API subscriptions, and how do I use them?

To use Availity's APIs, you must subscribe to a plan from your App. There are generally two types of subscriptions: Demo and Standard.

The Demo plan is the best starting point because it allows users to test and establish connectivity with our API endpoints, understand the flow of API calls, and generally get acquainted with our system. Availity automatically approves subscriptions to the Demo plan, which provides access to a sandbox environment and canned responses for each of the API endpoints. It does not allow for end-to-end testing or testing with any live data.

Once you have explored the Demo system, you can work with your Trading Partner Manager to set up your contract and upgrade your organization to the Standard Plan. The Standard plan gives full access to the REST APIs and data. See Getting Started for more information.

Why am I getting a 429 response code to all my API requests?

Both subscription types have two different transaction limits – a maximum allowed per second and a maximum allowed per day – as follows:

  • Demo: limited to 5 transactions per second and 500 per day
  • Standard: limited to 100 transactions per second/100,000 per day
Note: Every REST API call counts in your transaction limits, including the OAuth token call, each initial request, and subsequent polling requests.

A 429 response code indicates that you have exceeded one of these transaction limits. If you have exceeded the per-second limit, you can resume sending transactions after one second. If you have exceeded the per-day limit, you will be able to resume sending transactions at midnight UTC.

Availity does not have the capability to override these limits manually on an as-needed basis. If you consistently exceed your transaction limits on the Standard plan, please contact your Availity Trading Partner Manager to discuss a solution.

What happens if I forget or lose my client secret?

Your application client secret is stored as an encrypted value, and Availity cannot retrieve the unencrypted version to tell you the value. However, you can reset the client secret for your app, which will update the stored value and return the new value to you:

  1. Click Apps in the main menu, and then click the application in question.
  2. Click the Reset link in the Client Secret section.
  3. Make a note of the new client secret displayed at the top of the page. Use this new value to authenticate going forward.

Enhanced Claim Status

What is the Sender Number/SenderID required by Florida Blue?

Some users have reported receiving the following error message when requesting Enhanced Claim Status information from the payer Florida Blue:

A sender number is needed for this function. Please obtain a check
 or EFT number from a Florida Blue payment within the past 90 days and contact
 Availity Client Services at 1-800-282-4548 for assistance.

You can request a Florida Blue Sender Number/SenderID through Availity. Call Availity Client Services (ACS) at 1-800-282-4548 and supply the following information:

  • Organization type
  • Organization name
  • Organization physical address
  • Tax ID (Ensure that this ID is associated with the Florida Blue Provider ID)
  • Best contact phone number
  • Name of the Availity user requesting the Sender ID
  • Email
  • Availity Customer ID
  • Florida Blue Provider ID
  • Florida Blue check number
  • Check amount
  • Check date
  • Pay-to address  

Payer approval typically occurs within 24-48 hours. Once approved, the SenderID will appear in View Identifiers/Organization Identifiers on the Availity Essentials portal for you to capture and use in transactions.

I'm working with the Configurations API for Enhanced Claim Status and the response indicates that the payer does not support the HIPAA_276 or the VALUE_ADD_277 subtypes. How can I request Enhanced Claim Status data from this payer?

If the payer supports the MEMBER_ID option, follow these steps for best practice:

  1. Run an Enhanced Claim Status Summary call.

    This a proprietary call that does not use the 276/277 transaction, but returns high-level claim information as well as multiple claims.

  2. Next, run an Enhanced Claim Status Detail call with the claim number returned in the MEMBER_ID summary response from Step 1.

    This a proprietary call that does not use the 276/277 transaction, but returns detailed claim information for a single claim. See the Enhanced Claim Status reference documentation for more information.