Registry API overview

BirthTracks is the birth registry. This API is its import and interop surface — the way another EHR or an integrator feeds a birth record in as a FHIR R4 BFDR Bundle, so a provider enters each birth once instead of re-keying it here. You submit one course of care — mother, child, and the newborn observations — and the same canonical record powers both vital-records filing artifacts and outcome benchmarking. Capture once, emit both, programmatically.

What you can do

Submit a course of care — POST a FHIR R4 Bundle to the ingestion endpoint. Processing is asynchronous: you get an immediate receipt and poll for the result.
Check ingestion status — every submission returns an id you can poll until it reaches a terminal state, with per-record accept/reject detail.

What it deliberately does not do

Two limits are stated up front because both matter to the compliance conversation, and both are properties of the partner lane — an EHR vendor or integrator pushing on behalf of the practices it serves:

No filing lane by default. Vendors file vital records through their own EHR, so partner-submitted records are not given a filing spine. Filing through BirthTracks is not part of this integration and is not something a feed can turn on for itself.
Nothing identified is stored. Bundles arrive identified, but a masking step runs before anything is persisted, allow-listing a coarse spine — maternal age, a 3-digit ZIP prefix, race/ethnicity, and the newborn outcomes. No name, no date of birth, no address.

A practice pushing its own births under its own key is a different, identified lane and is not masked this way. See Partner onboarding for the full contract.

Scoped to your practice

A registry API key scopes everything you submit to your own practice, so you can exercise the full ingestion → validation → mapping path end to end. Mint a key, submit the Bundle in Getting started, and inspect the mapped result — all from these docs.

How records are shaped

A Bundle carries one course of care, or many — a Bundle whose entries are themselves Bundles holds one course of care per inner Bundle. Each course of care is:

Exactly one mother Patient (resolved from its BFDR meta.profile).
At least one child Patient.
The newborn Observations the registry lands — birth weight (LOINC 8339-4), gestational age (11884-4), and Apgar scores (9272-6, 9274-2).

See the data dictionary for the full canonical spine and the API reference for endpoint detail.

Authentication and errors

Every request carries a per-source bearer token (Authorization: Bearer rgk_...). Keys are minted per practice, scoped, and revocable; only a hash is stored, so a leaked database can never recover a usable credential.

Every error — auth, malformed request, and each rejected record in a partial batch — comes back as a FHIR OperationOutcome with the application/fhir+json content type, so you parse one error shape everywhere.