Real-Time Pharmacy Eligibility Checks via REST API
Before a pharmacy dispenses a medication, there's a critical question: is this patient actually covered? The E1 eligibility transaction answers that question in real time. It's the difference between confident dispensing and a rejected claim that wastes everyone's time.
What is an E1 eligibility check?
An E1 transaction is an NCPDP-standard eligibility verification request. It asks a PBM or insurance plan a simple question: "Is this member active, and what are their pharmacy benefits?" The response includes coverage status, group information, copay tiers, and sometimes formulary details.
Unlike a B1 billing claim (which actually submits a prescription for adjudication), E1 is read-only. It doesn't create a claim, doesn't affect accumulators, and doesn't trigger DUR alerts. It's a pure coverage inquiry: fast, safe, and essential for workflow optimization.
Why eligibility checks matter
Claim rejections are expensive. Every rejected claim means:
- •Wasted pharmacy technician time: researching the rejection, calling the patient or plan
- •Patient frustration: they're standing at the counter waiting, or worse, they leave
- •Lost revenue: if the patient goes to another pharmacy or doesn't fill at all
- •Resubmission costs: every claim attempt costs switch fees, even rejected ones
By running an eligibility check before submitting the claim, you catch coverage issues upfront (expired plans, incorrect BIN/PCN, terminated members) before they become rejected claims.
Traditional eligibility vs. REST API
Traditionally, E1 eligibility checks require the same infrastructure as claim submission: an NCPDP Telecommunication Standard implementation, a switch contract, binary protocol encoding, and certification. Most pharmacy management systems have this built in, but if you're building new software, you're looking at months of integration work just to ask "is this patient covered?"
With Starlight's E1 Eligibility API, it's a single JSON POST request. No binary encoding. No switch contract. No certification.
Checking eligibility with curl
Here's what a real eligibility check looks like through Starlight:
For eligibility checks, BIN and PCN are always the same per payer type. Starlight handles that routing for you. You just send the patient info and their cardholder ID:
curl -X POST https://starlight.claims/api/v1/eligibility \
-H "X-API-Key: your_api_key" \
-H "Content-Type: application/json" \
-d '{
"patient": {
"first_name": "JANE",
"last_name": "DOE",
"date_of_birth": "19850115",
"gender": "F",
"zip_code": "12345"
},
"insurance": {
"cardholder_id": "ABC123456789"
}
}'The response includes the patient's coverage details plus the BIN/PCN/Group you need for billing:
{
"response_status": "A",
"patient": {
"first_name": "JANE",
"last_name": "DOE",
"date_of_birth": "19850115",
"person_code": "001",
"relationship_code": "01"
},
"other_payers": [
{
"bin_number": "610014",
"pcn": "CADV",
"group_id": "RX9876",
"cardholder_id": "ABC123456789",
"payer_name": "ACME CORP PHARMACY BENEFITS"
}
]
}The other_payers array gives you everything needed to submit a B1 billing claim: BIN, PCN, Group, and Cardholder ID. This is the real workflow: check eligibility first, then use the returned payer details to bill.
Common response codes and what they mean
The eligibility response includes standard NCPDP response codes that tell you exactly what's happening:
A (Approved)
Patient is active and eligible. The response includes benefit details. Safe to proceed with the claim.
C (Captured)
Eligibility confirmed but with additional information. Review the message fields for details on limitations or restrictions.
R (Rejected)
Patient is not eligible under this plan. Check reject codes. Common reasons include terminated coverage, invalid member ID, or inactive group.
20 (Record Not Found)
The PBM has no record matching the submitted BIN/PCN/cardholder ID combination. Verify the information on the patient's insurance card.
25 (Missing/Invalid Info)
Required fields are missing or formatted incorrectly. Check date of birth format, person code, and cardholder ID length.
Best practices for eligibility workflows
- 1.Check at intake, not at pickup. Run eligibility when the prescription arrives, not when the patient is at the counter.
- 2.Cache results briefly. Eligibility rarely changes hour-to-hour. Cache for the session or the day to reduce API calls.
- 3.Handle multiple plans. Many patients have primary and secondary coverage. Check both if the primary returns a high copay.
- 4.Log everything. Eligibility responses are gold for troubleshooting rejected claims later. Store the full response.
Start checking eligibility in minutes
Starlight's E1 Eligibility API gives you real-time coverage verification with a single REST call. No switch contract. No binary protocol.