Coverage
Version payer observations without silently replacing their source history.
Claims
Submit delivered Care, request evidence and record line decisions.
Controls
Review amount identities, authority boundaries and reconciliation rules.
Integration architecture
The payer controls membership, Benefit design and adjudication policy. Heyrafiki controls the workflow contract, authorization boundary, retry behavior and audit evidence. The Practitioner controls the clinical record. A payment source supplies settlement evidence independently from payer advice.End-to-end flow
1
Establish the authority mapping
Map one payer tenant to one Heyrafiki Organization and issue a separate project for each environment. Grant only the scopes required by the integration.
2
Load Coverage
Send individual observations through
POST /coverages, or batches of up to 500 records through POST /coverage_batches. Each observation carries its source contract, source version, effective period and evidence references.3
Check the Benefit
Call
POST /eligibility_checks for the service date and requested amount. Treat ineligible as a decision with reason codes, not as a transport failure.4
Reserve authorization when required
Create a pre-authorization from the eligibility decision and covered Booking. The payer records the decision through
POST /preauthorizations/{preauthorization_id}/decisions.5
Submit delivered Care
Create the Claim only after the covered Session is delivered. Send service codes, units, amounts and evidence references. Clinical Notes and private Conversation content do not enter this contract.
6
Adjudicate every line
Request bounded evidence when necessary, then record a versioned policy reference, line amounts and coded reasons through
POST /claims/{claim_id}/adjudications.7
Reconcile payer advice
Send remittance advice with allocations to Claims. Heyrafiki keeps advice separate from independent settlement evidence so an advice file cannot assert that money moved.
Record the first Coverage observation
The same request shape works across supported HTTP clients. Amounts are integers in the currency’s minor unit.201 · Coverage observation
201 · Coverage observation
Replay and conflict behavior
Replay and conflict behavior
Repeating the same payload with the same idempotency key returns the original observation with
200. Reusing that key with different content returns 409 and writes no second observation.Source data contract
Control ownership
Retry and recovery rules
- Send an
Idempotency-Keyon every supported write. - Retry
429and retryable503responses only after the stated delay. - Treat a timeout after submission as unknown. Retry with the same idempotency key.
- Treat
409as a state or idempotency conflict that requires review. - Persist the
X-Request-Idwith the payer’s integration log. - Consume Webhooks idempotently using the stable event identifier.

