API processing
REST APIs and webhooks for every payer interaction
Skip the X12 plumbing. Use one REST surface for eligibility, claim submission, claim status, and ERA delivery across our entire payer directory. Signed webhooks for every state change.
Unified REST surface
/eligibility, /claims, /claim-status, /eras — same shape across every payer.
Signed webhooks
HMAC-SHA256 signed callbacks for claim acks, status changes, and ERA delivery.
OAuth 2.0 + API keys
Per-environment client credentials with scoped permissions and rotation.
Idempotency built-in
Idempotency-Key header on every write to safely retry across network failures.
FHIR R4 compatible
Optional FHIR Claim, ClaimResponse, Coverage, and EligibilityResponse resources.
Typed SDKs
TypeScript, Python, and .NET SDKs generated from OpenAPI 3.1.
Example: real-time eligibility
POST /v1/eligibility
Authorization: Bearer <token>
Idempotency-Key: 7c2f...
{
"payer_id": "12345",
"provider": { "npi": "1234567890" },
"subscriber": {
"member_id": "ABC123456",
"first_name": "Jane",
"last_name": "Doe",
"date_of_birth": "1985-04-12"
},
"service_type": "30"
}Frequently asked questions
- What authentication is supported?
- OAuth 2.0 client credentials and API keys with per-environment scopes. Mutual TLS available for enterprise.
- Do you offer real-time eligibility?
- Yes. Sub-second 270/271 eligibility on every supported payer via REST, with optional caching layer.
- Are webhooks signed?
- All webhook deliveries are HMAC-SHA256 signed and retried with exponential backoff for 24 hours.
- What SLAs do you provide?
- 99.95% uptime, p95 < 400 ms for eligibility, p95 < 2 s for claim submission acks. Status page and incident notifications included.
Ready to request api access?
Our team can scope your connectivity, automation, or reporting needs in a single call.