Importing records
This page is for feeding births in programmatically — a partner EHR, an integrator, or a registry-only tenant that brings records in through the API rather than through the app. It frames the import lanes and points at the contract for each; the endpoint detail lives in the API reference.
The lanes
Section titled “The lanes”- FHIR R4 Bundle push (bearer-key ingest). The primary lane: POST a FHIR R4
BFDR Bundle to the ingestion endpoint under a
per-source bearer token (
Authorization: Bearer rgk_...). Processing is asynchronous — you get an immediate receipt and poll for the per-record result. Walk it end to end in Getting started, and see the Registry API overview for what the lane does and deliberately does not do (no filing spine on partner submissions, nothing identified stored on the masked partner lane). - SMART on FHIR pre-fill. The interactive lane: a clinician launches BirthTracks from inside their EHR and the launched patient’s data pre-fills a single course of care. See SMART on FHIR (EHR launch).
The registry API lane is programmatic — records arrive as FHIR Bundles over the endpoint above, under a key minted per practice that scopes everything you submit to your own practice. (A practice working inside the BirthTracks app brings its own records in from the Birth Registry head’s Imports tab — the Import births wizard, which writes the identified roster — but that is an app surface, not this API.) The full ingest → validation → mapping contract is in Partner onboarding.
Bringing in a spreadsheet as a BirthTracks customer
Section titled “Bringing in a spreadsheet as a BirthTracks customer”If you use the BirthTracks app and want to bring a spreadsheet of your own births in, that is a different, identified lane: the Import births wizard on the Birth Registry head’s Imports tab writes each row to your patient roster and the registry, with no API key required. The programmatic lanes on this page are for feeds that push on behalf of a practice, not for a customer importing their own records.