Insurance Eligibility Verification API for Pharmacy

What is insurance eligibility verification?

Eligibility verification confirms that a patient has active pharmacy benefit coverage and retrieves their plan details in real-time. In the pharmacy world, this is the NCPDP E1 transaction — a standardized request sent through pharmacy claim switches to PBMs (Pharmacy Benefit Managers).

A successful eligibility check returns:

Why real-time eligibility verification matters

Without eligibility verification, pharmacies face:

Real-time eligibility checks solve all of this before the pharmacist fills the prescription. It's the difference between a smooth workflow and a mess at the counter.

Traditional E1 eligibility vs. Starlight API

Here's what building eligibility verification looks like with and without Starlight:

Making an eligibility check

A complete E1 eligibility request with Starlight looks like this:

curl -X POST https://starlight.claims/api/v1/eligibility \
  -H "X-API-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_type": "E1",
    "patient": {
      "first_name": "JANE",
      "last_name": "DOE",
      "date_of_birth": "19850615",
      "gender": "F",
      "zip_code": "90210"
    },
    "insurance": {
      "bin_number": "610014",
      "pcn": "MEDDPRIME",
      "group_id": "RXGROUP01",
      "cardholder_id": "DOE123456789",
      "person_code": "001",
      "relationship_code": "01"
    }
  }'

That's it. No binary encoding, no segment terminators, no field-position math. Just the patient and insurance identifiers you already have.

Understanding the eligibility response

When the patient is found and has active coverage, you get back a structured JSON response:

{
  "header": {
    "responseStatus": "A",
    "transactionResponseCode": "E"
  },
  "eligibility": {
    "status": "active",
    "cardholderFirstName": "JANE",
    "cardholderLastName": "DOE",
    "coverageStartDate": "20250101",
    "coverageEndDate": "20261231",
    "planName": "PRIME THERAPEUTICS RX"
  },
  "insurance": {
    "binNumber": "610014",
    "pcn": "MEDDPRIME",
    "groupId": "RXGROUP01",
    "cardholderId": "DOE123456789"
  },
  "otherPayers": [
    {
      "payerType": "secondary",
      "binNumber": "003858",
      "pcn": "A4",
      "groupId": "MEDICAREB",
      "cardholderId": "1EG4TE5MK73"
    }
  ],
  "message": "PATIENT ELIGIBLE"
}

Key fields to look at: responseStatus "A" means the PBM accepted the request. eligibility.status tells you coverage is active. And otherPayers gives you secondary insurance for coordination of benefits — critical for Medicare Part D patients who often have multiple payers.

Handling different response scenarios

Not every eligibility check returns a clean "active" result. Here's how to handle the common scenarios:

Maximizing patient match rates

The accuracy of eligibility checks depends on the data you send. Here's what gets the best results:

The Starlight API accepts all of these fields. Send as much as you have — the more data, the higher the match rate.

Medicare Part D eligibility checks

Medicare Part D patients often have the most complex eligibility scenarios: multiple payers, Low Income Subsidy (LIS) status, coverage gap ("donut hole") considerations, and coordination with Part A/B. The Starlight API handles all of this through the same endpoint.

The eligibility response for Medicare patients includes additional fields:

• • LIS level — whether the patient qualifies for reduced copays
• • Coverage phase — deductible, initial coverage, gap, catastrophic
• • Other payers — Medicaid, employer supplemental, TRICARE coordination

This is especially valuable for mail-order pharmacies and PBM analytics platforms that need to route claims correctly across payers.

What you can build with eligibility data

Real-time eligibility verification unlocks several high-value applications:

• • Pharmacy POS systems: verify coverage at intake, before the prescription hits the queue
• • Price transparency tools: show patients what they'll owe before they visit the pharmacy
• • Telehealth platforms: check formulary coverage during the prescriber visit to avoid post-visit rejections
• • Patient onboarding flows: validate insurance at signup for specialty pharmacy programs
• • Benefits verification automation: batch-check eligibility for scheduled refills overnight
• • Coordination of benefits engines: identify all payers to maximize reimbursement

Understanding BIN and PCN numbers

Every eligibility check requires a BIN (Bank Identification Number) and usually a PCN (Processor Control Number). These route your request to the correct PBM:

• • BIN — 6-digit number identifying the claims processor (e.g., 610014 = Prime Therapeutics)
• • PCN — additional routing code used by the processor to identify the specific plan

These are found on the patient's pharmacy benefit card. If you need to look up BIN/PCN combinations, check our BIN/PCN Lookup API guide.