Catch up after an outage
Read a checkup or a member with the read API, and list the checkups your system missed.
A webhook is a hint, not the record. Your backend reads the record from the read API: a checkup's bundle, a member as they are now, and the checkups you missed while your receiver was down.
The read API
Your backend calls it with an OAuth2 client-credentials token, as Authentication describes: one client per integration, and tokens that last five minutes.
| Route | Answers |
|---|---|
GET /v1/fhir/checkups/{checkup_id} | The checkup's FHIR Bundle: the same one its webhook carried or would carry |
GET /v1/fhir/Patient/{patient_id} | The member's FHIR Patient, as it is now |
GET /v1/checkups?completed_from=&after=&limit= | Your completed checkups, a page at a time, to catch up after an outage |
A checkup or member that is not your organization's answers 404, as if it did not exist. What the
bundle and the Patient hold is on FHIR.
Not decided yet: the hosts and exact paths; what each item of the catch-up list holds; whether the list goes back before your webhook was switched on; the error body; the rate limits.
List what you missed
Ask for the checkups completed since your receiver last took a delivery:
curl "https://api.example.com/v1/checkups?completed_from=2026-10-01T00:00:00Z" \ --header "Authorization: Bearer $YOUTH_ACCESS_TOKEN"Then read the bundle of each checkup you do not have yet.
Skip what you already have
A checkup you stored from a delivery comes again in the list. Skip the checkup ids you already
have, as you skip an event_id you have seen.
Make it routine
Run the same list on a schedule, every hour for example, from the newest checkup you have. Then an
event lost on the way, or a receiver that answered 200 but failed afterwards, costs a delay and
never a checkup.