When you submit the following requests to the Real-Time Eligibility Check endpoint with a test API key, Stedi returns mock benefits data from the specified payer you can use for testing. You can also submit these mock requests through the New eligibility check form in the UI when Test mode is enabled.
Mock requests are free for testing purposes and won’t incur any charges in your Stedi account.

​
Test API key

When submitting these mock requests to the API, you must use a test Stedi API key for authentication. When using a test API key, you can only send the following mock requests to the endpoint. Stedi returns an error if you try to send production data with a test API key.

​
API clients

You may want to use an API client to make testing and debugging easier. We don’t recommend using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds. Visit API clients for a list of recommended clients you can use instead.

​
Medical - Active coverage

Request notes:
  • encounter: Only service type code 30 is supported.
  • provider: You can use any organization name and any NPI, as long as it passes check digit validation. To generate a dummy NPI, you can use this free tool.
  • subscriber: You must use the exact values in the test request. Other birth dates, first names, last names, member IDs, and Social Security Numbers return errors.

​
Dependent

Each of these examples represent an eligibility check for a dependent. An individual qualifies as a dependent for eligibility checks when they are listed as a dependent on the subscriber’s insurance plan AND the payer cannot uniquely identify them through information outside the subscriber’s policy. These example requests follow best practices for structuring eligibility checks. Specifically, all requests include the dependent’s information, including their date of birth, in the dependents array. Some payers may allow different structures, such as sending the dependent’s information in the subscriber object with the subscriber’s member ID. However, we recommend following the guidance outlined in the Real-Time Eligibility Check endpoint documentation for the most reliable results across all payers. The way dependent information is included in the response varies by payer. Some contain the dependent’s information in the subscriber object. Some include the actual subscriber’s information in the subscriber object and the dependent’s information in the dependents array. Aetna In this example, the dependent Jordan is the subscriber John’s child. Jordan’s information is returned in the dependents array in the response.
Anthem Blue Cross Blue Shield of CA In this example, the dependent John is the subscriber Jane’s spouse. John’s information is returned in the dependents array in the response.
Blue Cross and Blue Shield of Texas In this example, the dependent Jane is the subscriber John’s child. Jane’s information is returned in the dependents array in the response.
Cigna In this example, the dependent Jordan is the subscriber’s child. In the response, Jordan is returned in the subscriber object with no dependents array, even though they are a dependent.
Oscar Health In this example, the dependent Jane is the subscriber John’s child. Jane’s information is returned in the dependents array in the response.
UnitedHealthcare In this example, the dependent Jane is the subscriber John’s spouse. Jane’s information is returned in the dependents array in the response.

​
Subscriber only

The following examples request benefits information for the subscriber only. The subscriber’s information is sent in the subscriber object in the request. The payer’s response contains the subscriber’s information in the subscriber object and doesn’t include any dependent information. Aetna
Ambetter
Cigna
Humana
Kaiser Permanente Northern California
National Centers for Medicare & Medicaid Services (CMS)
UnitedHealthcare

​
MBI lookup for CMS checks

You must include the patient’s Medicare Beneficiary Identifier (MBI) in every eligibility check you submit to the Centers for Medicare and Medicaid Services (Payer ID: CMS). When patients don’t know their MBI, you can use Stedi’s eligibility APIs to perform an MBI lookup using their Social Security Number instead. Visit MBI lookup for more information.

​
Medical - Inactive coverage

The following example requests benefits information for the subscriber. UnitedHealthcare

​
Dental

The following example requests benefits information for the subscriber. Request notes:
  • encounter: Only service type code 35 is supported.
  • provider: You can use any organization name and any NPI, as long as it passes check digit validation. To generate a dummy NPI, you can use this free tool.
  • subscriber: You must use the exact values in the test request. Other birthdates, first names, last names, and member IDs return errors.
Ameritas
Anthem Blue Cross Blue Shield of CA
Cigna
Metlife
UnitedHealthcare

​
Common AAA errors

The following requests return mock data for the most common Payer AAA errors. Visit Eligibility troubleshooting for a complete list of AAA error codes, other common eligibility check issues, and recommended resolution steps.

​
42 - Unable to respond at current time

The following example request returns a 42 AAA error code, indicating that the payer is unable to respond at the current time. This is typically a temporary issue with the payer’s system, but it can also be an extended outage or the payer throttling your requests.

​
43 - Invalid/Missing Provider Identification

The following example request returns a 43 AAA error code. This error can occur if provider’s NPI is not registered with the payer, the provider’s NPI is not registered correctly with the payer, or the payer requires an agreement.

​
72 - Invalid/Missing Subscriber/Insured ID

The following example request returns a 72 AAA error code. This error can occur if the subscriber member ID was incorrect in the request, the request does not meet the payer’s requirements for the subscriber ID, or there is another unidentified error in the request data.

​
73 - Invalid/Missing Subscriber/Insured Name

The following example request returns a 73 AAA error code. This error can occur if an incorrect subscriber name was submitted, the subscriber name was missing, the subscriber name was spelled incorrectly, or the request doesn’t meet the payer’s requirements for the subscriber’s name.

​
75 - Subscriber/Insured Not Found

The following example request returns a 75 AAA error code. This error occurs when the payer can’t find the subscriber in their database. You should verify the subscriber details and try sending different combinations of firstName, lastName, dateOfBirth, and memberId. Note that not all search combinations are supported by all payers.

​
79 - Invalid Participant Identification

The following example request returns a 79 AAA error code. This error occurs when there is a problem connecting with the payer. You should contact Stedi support for assistance.