---
title: "How Eligibility Responses Work in Test vs Production"
slug: "how-eligibility-responses-work-in-test-vs-production"
updated: 2026-02-10T15:32:48Z
published: 2026-02-10T15:32:48Z
canonical: "docs.claim.md/how-eligibility-responses-work-in-test-vs-production"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://docs.claim.md/llms.txt
> Use this file to discover all available pages before exploring further.
# How Eligibility Responses Work in Test vs Production
### **1. Are test eligibility responses mocked?**
Yes. In the test environment, the Eligibility API always returns the same sample response, regardless of the payer or the member data submitted. This behavior is intentional and is designed to allow you to:
- Verify connectivity
- Validate authentication
- Build and test your request formatting and response parsing logic
The test environment is **not** intended to simulate real-world payer behavior.
This is also documented in the [**API Quickstart Guide**](https://docs.claim.md/docs/test-account-quickstart-guide) (see the Eligibility section).
To see real payer behavior—such as different responses by payer, patient, or benefit type—you must move to a **production account**.
---
### **2. How should “unsuccessful” or “not eligible” scenarios be handled?**
Because the test environment always returns the same successful sample response, you will not encounter true “no active coverage” or “member not found” scenarios while testing.
In production, determining whether a patient is eligible is **not** a simple yes/no decision. Your integration logic should evaluate the returned benefit data, including:
- Coverage status
- Plan effective and termination dates
- Benefit types
- Copays, coinsurance, and deductibles
Eligibility decisions should be made based on:
- The date of service (is coverage active on that date?)
- The type of service being checked (e.g., office visit, behavioral health, telehealth)
- Any limitations or exclusions listed in the response
A payer may return:
- Explicit messages such as “insured not found” or “coverage terminated”
- Valid coverage data that does not include benefits relevant to the requested service type
For this reason, your application should interpret the **benefit details**, not rely solely on the presence or absence of an error flag.
---
### **3. What is the difference between `error`, `elig`, and `elig.error` in the API response?**
Below is a simplified structure of the Eligibility API response:
```
JSONJSON{
"result": {
"error": "...",
"elig": {
"error": "...",
"...": "benefit data"
}
}
}
```
#### **result.error**
- Indicates an error at the Claim.MD system level
- Common causes include:
- Missing or invalid data
- Enrollment or payer minimum requirement failures
- Malformed requests or internal processing errors
- Unresponsive or unusable payer EDI responses
If `result.error` is populated, the request should be treated as **failed**, and you may want to retry or display a technical error to the user.
#### **result.elig**
- Indicates that Claim.MD successfully reached the payer and parsed a response
- Contains benefit data (when available) and payer-originated messages
#### **result.elig.error**
- Comes directly from the payer’s EDI system
- May include messages such as:
- “Insured not found”
- “Subscriber not found”
- “Member ID not found”
- “Coverage terminated”
These messages are important, but they are **not the sole indicator of eligibility**. Even if `result.elig.error` is empty, benefit data must still be reviewed to determine whether coverage applies to the requested service.
---
### **Recommended Production Logic Flow**
1. If `result.error` is present, treat the response as a system or transport error.
2. Else if `result.elig.error` is present, handle the response as a payer-level failure or “no coverage/member not found” scenario.
3. Else, evaluate the benefit data in `result.elig` to determine whether coverage is active and applicable.
For payer-side message codes, refer to the **Eligibility Code Reference (PDF)**.
---
### **Test vs Production Recap**
**Test Environment**
- Returns one static, successful sample response
- Used to:
- Validate authentication
- Confirm request formatting
- Build and test parsing logic and UI behavior
**Production Environment**
- Returns live responses from payers
- Includes:
- Real “member not found” and “no coverage” scenarios
- Full benefit structures used for eligibility determinations