API Keys
Use scoped server-side keys for sandbox and partner integrations. Never expose keys in browser code or mobile clients.
API Reference
This reference documents the integration model for partners. It keeps examples synthetic, avoids protected health information, and points production access through partner review.
Production credentials are issued only after security, privacy, and commercial review.
Authentication
Developer access should keep secrets server-side, scope keys by environment, and separate employer analytics from employee bill workflows.
Use scoped server-side keys for sandbox and partner integrations. Never expose keys in browser code or mobile clients.
Enterprise platform connections can use OAuth-style authorization when the partner needs user-initiated handoff flows.
Every webhook payload should be verified with timestamped HMAC signatures before work is queued.
Quickstart
The quickstart shows the shape of the request without uploading files or showing medical records on a public page.
POST /v1/billsconst response = await fetch("https://api.preflixai.com/v1/bills", {
method: "POST",
headers: {
"Authorization": "Bearer PREFLIXAI_API_KEY",
"Content-Type": "application/json"
},
body: JSON.stringify({
external_id: "case_104",
document_refs: ["doc_bill", "doc_eob"]
})
});
const bill = await response.json();Endpoints
The table is intentionally small so partners can map each endpoint to a specific user or operations workflow.
| Method | Path | Description |
|---|---|---|
| POST | /v1/bills | Create a bill record and attach upload references. |
| POST | /v1/bills/{bill_id}/audit | Start an audit job after required documents are attached. |
| GET | /v1/bills/{bill_id}/report | Retrieve a structured report once the audit is complete. |
| GET | /v1/prices | Search price transparency context by procedure, code, payer, and location. |
| GET | /v1/cpt-lookup | Return plain-language code context and benchmark notes. |
| POST | /v1/letters | Draft a dispute or records-request letter from selected findings. |
Schemas
Examples use synthetic identifiers and no real patient, provider, payer, or bill details.
JSONA bill record contains partner references, document status, audit status, and safe user-facing display fields.
{
"id": "bill_8f4",
"status": "ready_for_audit",
"document_count": 2,
"created_at": "2026-01-15T18:22:00Z"
}JSONFindings are structured for risk, evidence notes, suggested next steps, and downstream letter generation.
{
"finding_id": "find_21",
"risk": "medium",
"category": "duplicate_charge",
"next_step": "request_itemized_review"
}Errors
Error responses should be actionable, retry-safe where possible, and careful not to echo protected document content.
| Status | Reason | Next Step |
|---|---|---|
| 400 | Invalid request | Fix schema, missing fields, or unsupported file references. |
| 401 | Unauthorized | Check key scope, environment, and Authorization header. |
| 409 | Workflow conflict | Confirm bill status before restarting an audit or letter job. |
| 422 | Document needs review | Ask the user for a clearer bill, EOB, or missing context. |
| 429 | Rate limited | Back off with jitter and retry after the returned window. |
SDKs And Postman
Production SDKs should reduce signing mistakes, centralize retries, and keep sensitive data out of logs.
Helper package shape for server-side bill records, audit jobs, report polling, and webhook verification.
Helper package shape for advocacy operations, async audit workflows, and internal case-management automation.
The collection should include sandbox examples, environment variables, and signature verification samples.
Next Developer Step