Participation and correction
Add, correct, or remove an endpoint
If we got something wrong about your organization, we would rather be corrected than counted right.
We are missing your endpoint
Payer FHIR base URLs are not predictable from company names, so this registry is built one developer portal at a time and is certainly incomplete. Absence from this list means no public base URL was found, not that no API exists.
We need the base URL and a link to where it is published, because confirming the publisher is who the entry claims is what verification means here. Nothing is added on an unverified submission.
Something here is wrong
This has happened. A live payer endpoint was recorded as dead because a middlebox on the probing network intercepted TLS and the error surfaced as one uninformative word. Probing now runs from more than one vantage, and reaching an endpoint from any of them settles that it is up. That did not solve the problem above, and we should not imply it did. It removed one shape of it — a fault local to a single host — and left the shape that matters to you untouched.
What those vantages are, exactly: three GitHub-hosted runner images (Ubuntu, macOS, Windows). They are three hosts on one provider's network, not three independent networks. They cannot catch a source-address rule, bot filter, geo rule, rate limit, or TLS interception applied to that provider's address space, because that hits all three at once and looks exactly like agreement. So when all three fail, the page says the endpoint was not reached from that network on that day. It does not say the endpoint is down, and it publishes no grade and no score — not a zero, which would be a measurement we did not make.
This is not hypothetical, and it is not rare. On 12 September 2026, of the 14 endpoints here that no vantage reached, re-probing by hand from an ordinary residential network found 4 that answered — two of them with an HTTP 2xx and a certificate that verified, which is exactly the criterion all three runners had just failed. If your endpoint is listed as not reached and you believe it is serving, you are very likely right.
You do not need to prove anything before asking us to look again.
Our probe contract
What we do to your servers
We ask for two documents per endpoint per probing run: /metadata and
/.well-known/smart-configuration. Two documents is not always two requests, and the
honest bound is the one worth publishing: if your server answers with a redirect, following it
costs another GET. We follow at most three hops per document, so the worst case is four requests
per document and eight per endpoint per probing run. Three probing runs a day,
one per runner image, so the ceiling for a scheduled day is 24 requests to any one
endpoint. Two per document, four per endpoint, is the normal case and the only one we
ask for; reaching 24 needs your own server to redirect three times on both paths. The run that
publishes this site adds none: it grades the documents those runs already retrieved.
Requests carry an identifying User-Agent with a contact address. We never authenticate, never
register for API access, never request patient data, and never probe beyond those two paths.
That scope is what is enforced on a redirect, on every hop: we follow a Location
only when it still names one of those two paths over HTTPS. The host may change — a payer
moving its FHIR service behind a CDN or a versioned path is ordinary, and refusing that would
break honest servers — but a redirect to anything else, or to plain HTTP, is refused, the
run records that it retrieved nothing, and your endpoint is published as not
observed rather than graded on a document we were pointed at.
Publishing is triggered on a schedule and by hand, not by commits, because a commit says nothing
about your endpoint and a commit-triggered rebuild once turned an ordinary working day into
dozens of requests to every endpoint here.
Grades describe observable properties of public documents. They are not audits, not compliance determinations, and not statements about care quality.