How to Submit Pharmacy Claims via API
Submitting pharmacy claims has traditionally required months of integration work: NCPDP certification, switch contracts, binary protocol implementation, and ongoing payer sheet maintenance. Starlight API reduces all of this to a single JSON POST request. This guide walks you through both approaches so you understand what's happening under the hood, and why the API approach saves months of work.
The traditional claims submission process
Before Starlight, submitting a pharmacy claim programmatically meant working through a complex chain of requirements. Here's what the process looks like:
- 1.Switch contract: Negotiate and sign an agreement with a pharmacy claim switch vendor (RelayHealth, Change Healthcare, etc.)
- 2.NCPDP membership: Join NCPDP to access the Telecommunication Standard specification ($$$)
- 3.Protocol implementation: Build an encoder/decoder for NCPDP Telecom D.0's binary format with 400+ field definitions
- 4.Certification testing: Pass NCPDP certification by submitting test claims that demonstrate correct protocol handling
- 5.Payer sheet management: Implement per-payer field requirements that vary across hundreds of PBMs
- 6.Production go-live: Coordinate with your switch vendor for production connectivity (VPN, dedicated line, or internet)
This process takes 3–6 months minimum and requires dedicated engineers who understand healthcare data standards. Most startups simply can't justify the investment.
What Starlight changes
Starlight sits between your application and the pharmacy claims network. We handle the switch connectivity, NCPDP encoding/decoding, certification, and payer sheet management. You get a clean REST API that accepts and returns JSON.
Submitting your first claim
Here's a complete B1 claim billing request using curl. This single command does what traditionally required an entire NCPDP stack:
curl -X POST https://starlight.claims/api/v1/submit \
-H "X-API-Key: your_api_key" \
-H "Content-Type: application/json" \
-d '{
"transaction_type": "B1",
"patient": {
"first_name": "JOHN",
"last_name": "SMITH",
"date_of_birth": "19900301",
"gender": "M",
"zip_code": "54321"
},
"insurance": {
"bin_number": "999999",
"pcn": "TEST",
"group_id": "GRP999999",
"cardholder_id": "SAMPLE123456",
"person_code": "002",
"relationship_code": "02"
},
"prescription": {
"rx_number": "999000001234",
"fill_number": "1",
"product_id": "00000000000",
"quantity_dispensed": "28",
"days_supply": "28",
"date_written": "20260101",
"daw_code": "0",
"prescriber_id": "1234567890",
"prescriber_last_name": "SAMPLE",
"prescriber_phone": "5555555555"
},
"pricing": {
"ingredient_cost": "0.00",
"dispensing_fee": "0.00",
"usual_customary": "0.00",
"gross_amount_due": "184.80"
}
}'Understanding the response
The API returns a structured JSON response with the PBM's adjudication result. No binary parsing required:
{
"header": {
"responseStatus": "A",
"transactionResponseCode": "P",
"authorizationNumber": "0987654321"
},
"pricing": {
"patientPayAmount": 10.00,
"ingredientCostPaid": 42.00,
"dispensingFeePaid": 2.00,
"totalAmountPaid": 44.00,
"basisOfReimbursement": "MAC"
},
"dur": {
"responseCodeCount": 0
},
"message": "CLAIM PAID"
}A responseStatus of "A" means accepted. The pricing section tells you exactly what the PBM paid and what the patient owes. No guessing, no binary decoding. Just clean data.
Handling rejections
When a claim is rejected, you get structured reject codes with human-readable messages:
{
"header": {
"responseStatus": "R",
"transactionResponseCode": "R"
},
"rejectCodes": [
{
"code": "75",
"description": "PRIOR AUTHORIZATION REQUIRED"
},
{
"code": "76",
"description": "PLAN LIMITATIONS EXCEEDED"
}
],
"message": "CLAIM REJECTED"
}NCPDP defines over 100 standard reject codes. Common ones include refill-too-soon (79), drug not covered (70), and prior authorization required (75). Your application logic can branch on these codes to guide the pharmacist or patient through resolution.
Authentication and environments
Starlight uses API key authentication via the X-API-Key header. You'll receive separate API keys for sandbox and production:
- • Sandbox: test claims against simulated PBMs with predictable responses. No real adjudication.
- • Production: live claims routed through real pharmacy switches to real PBMs.
The sandbox environment uses identical request/response schemas, so your integration code works in both environments without modification. Just swap the API key.
What you can build
With programmatic claims access, the possibilities open up:
- • Pharmacy management systems: full claims workflow without switch contracts
- • Eligibility checkers: verify patient coverage before dispensing
- • Price transparency tools: show patients their copay before they arrive
- • Prior authorization automation: detect PA rejections and trigger workflows
- • Analytics platforms: aggregate claims data for payer performance insights
- • Mail-order pharmacies: automated dispensing and claims submission pipelines
Start submitting claims today
Get your API key and submit your first test claim in minutes. No switch contract. No NCPDP certification. Just JSON.