# FinchNode

> With a FinchNode account, developers get free, self-serve production access to real, patient-authorized records. The platform supports read-only health applications in the United States, with provider search, hosted source authorization, application-specific consent, normalized records, sync state, and lifecycle webhooks.

## Free, self-serve production access.

[Production access is free and self-serve with an account.](https://finchnode.com/signup)

With a FinchNode account, developers get free, self-serve production access to real, patient-authorized records.

Free ($0/month) includes one production application, a synthetic sandbox included with every account, hosted consent and patient controls, scheduled sync, and signed webhooks. Pro ($99/month) includes up to 5 production applications, email support, and everything in Free. Usage-based pricing is not in effect.

The public demo API serves twelve named synthetic scenarios from two synthetic sources, Northstar Health System and Quillhaven Medical Group, for free without an account. Create a FinchNode account for free, self-serve production access to real, patient-authorized records. The demo itself cannot access real patient data. Its /users/{subject}/records route returns normalized health records; the legacy /patients routes return category-grouped FHIR resources. Consent and sync metadata are explicitly simulated; real requests require a live key, current patient authorization, and available sources.

Free production access and the public synthetic demo

| What you get | Free production plan | Public demo API |
| --- | --- | --- |
| Price | $0/month | $0 |
| Patient data | Real records with patient authorization and consent | Twelve named synthetic scenarios only |
| EHR access | Availability varies by organization and granted scopes | No live EHR connections |
| Applications and usage | 1 production application; no usage-based pricing; fair-use rate limits per API key | Rate-limited sample API |
| Getting started | Account and complete app settings; owner enables production | No account or API key |

Owners enable production when application settings are complete; FinchNode can suspend access. Live reads require production credentials and patient authorization and consent; availability varies by organization and scopes.

[Free production EHR API](https://finchnode.com/ehr-integration-api) · [Plans and application limits](https://finchnode.com/#pricing)


FinchNode does not claim universal EHR coverage, write-back, provider-side bulk access, scheduling, or general HL7 interface-engine functionality. Production availability depends on the source, organization, application approval, granted scopes, patient authorization, and data returned.

## Canonical product pages

- [FinchNode home](https://finchnode.com/)
- [Free production EHR integration API](https://finchnode.com/ehr-integration-api)
- [Production pricing and application limits](https://finchnode.com/#pricing)
- [Integration evidence directory](https://finchnode.com/integrations)
- [Developer docs](https://finchnode.com/docs)
- [Public synthetic demo API — no account needed](https://finchnode.com/docs/get-started/demo-api): Epic production access is free and self-serve with a FinchNode account at https://finchnode.com/signup.
- [Synthetic FinchNode Visualizer](https://finchnode.com/tools/finchnode-visualizer)
- [FinchNode Engineering author profile](https://finchnode.com/authors/finchnode-engineering)

## Docs

- [FinchNode docs](https://finchnode.com/docs.md): FinchNode lets your app read a patient's health records after they connect a health system and agree to share.
- [Quickstart](https://finchnode.com/docs/get-started/quickstart.md): Get a synthetic patient's records into your terminal with a sandbox key, no hospital sign-in needed.
- [Demo API](https://finchnode.com/docs/get-started/demo-api.md): Call fictional patient records with no key and no account.
- [Environments and keys](https://finchnode.com/docs/get-started/environments-and-keys.md): Build against the sandbox with a ck_test_ key, then switch to a ck_live_ key for real patients.
- [How Connect works](https://finchnode.com/docs/connect/how-connect-works.md): A Connect session is a link that lets one patient connect a health system and choose what to share with your app.
- [Create a session](https://finchnode.com/docs/connect/create-a-session.md): Create a Connect session from your server with the categories you need, then send the patient to its url.
- [After the patient connects](https://finchnode.com/docs/connect/after-the-patient-connects.md): Tie a finished session to your own user by storing the session ID when you create it and reading the subject when it completes.
- [The patient's experience](https://finchnode.com/docs/connect/the-patients-experience.md): Here is every screen a patient sees in Connect, in order, so you can explain it before you send them.
- [Health systems](https://finchnode.com/docs/connect/health-systems.md): These are the health system families Connect includes, and what can differ from one organization to the next.
- [Record model and categories](https://finchnode.com/docs/records/record-model.md): Every record comes back in one normalized shape, grouped into ten categories, with its source and codes attached.
- [Read and paginate](https://finchnode.com/docs/records/read-and-paginate.md): Import a category by following its cursor until hasMore is false, then keep it current with the change feed.
- [Change feed](https://finchnode.com/docs/records/change-feed.md): After your first import, read only what changed in a category, including deletions.
- [Freshness, partial and stale records](https://finchnode.com/docs/records/freshness.md): Use the snapshot metadata to tell how current a record is, what's missing, and whether a source failed.
- [Consent, revocation, and deletion](https://finchnode.com/docs/records/consent-revocation-deletion.md): Every read checks consent first, so plan for sharing to end and for deletion requests.
- [Receive and verify](https://finchnode.com/docs/webhooks/receive-and-verify.md): Verify each webhook's signature against the raw body, ignore duplicates, and answer within five seconds.
- [Retries and duplicates](https://finchnode.com/docs/webhooks/retries-and-duplicates.md): FinchNode retries a failed delivery for about 41 hours over eight attempts, so your endpoint must handle repeats and out-of-order events.
- [Scenarios](https://finchnode.com/docs/testing/scenarios.md): Pick a named synthetic patient to test a specific record shape or failure.
- [Sandbox controls](https://finchnode.com/docs/testing/sandbox-controls.md): Drive a synthetic patient through new records, revoked consent, expiry, and a failed sync on demand.
- [Conformance](https://finchnode.com/docs/testing/conformance.md): Run your integration against a synthetic patient and get a report on how it handled pagination, rate limits, revocation, and webhooks.
- [MCP server](https://finchnode.com/docs/ai-agents/mcp-server.md): Give an AI agent the same consented access your server has, through FinchNode's MCP endpoint.
- [Delegated agent credentials](https://finchnode.com/docs/ai-agents/agent-credentials.md): Hand an agent a short-lived credential for one patient and a few categories instead of your app key.
- [Coding-agent plugin](https://finchnode.com/docs/ai-agents/coding-agent-plugin.md): Point your coding agent at FinchNode's Markdown docs today; the FinchNode coding-agent plugin isn't published yet.
- [TEFCA Individual Access](https://finchnode.com/docs/tefca/individual-access.md): How a person verifies once and requests their own records across the national networks, and what FinchNode gives back.
- [TEFCA sandbox API](https://finchnode.com/docs/tefca/developer-api.md): Build an app that discovers and retrieves synthetic TEFCA-style records with your FinchNode sandbox key.
- [Try it in the console](https://finchnode.com/docs/tefca/try-it-in-the-console.md): Step through TEFCA Individual Access with a synthetic patient in the FinchNode console.
- [Go-live checklist](https://finchnode.com/docs/go-live/checklist.md): Tick these off before your first production key; the list is saved in this browser.
- [Handling patient data](https://finchnode.com/docs/go-live/handling-patient-data.md): Everything FinchNode returns about a patient is health data, so keep it out of places it doesn't belong.
- [Errors](https://finchnode.com/docs/resources/errors.md): The error codes the API returns, what causes each, and how to fix it.
- [Rate limits](https://finchnode.com/docs/resources/rate-limits.md): Each API key gets 300 requests a minute; when you go over, wait for Retry-After and try again.
- [Glossary](https://finchnode.com/docs/resources/glossary.md): The terms these docs use, each defined once.
- [API reference](https://finchnode.com/docs/api.md): Base URL, authentication, errors, and every FinchNode API operation.
- [Platform API](https://finchnode.com/docs/api/platform.md): Health, your application, and delegated agent credentials.
- [Connect API](https://finchnode.com/docs/api/connect.md): Create, read, and cancel hosted Connect sessions.
- [Records API](https://finchnode.com/docs/api/records.md): Subjects, normalized records, categories, and change feeds.
- [Consent API](https://finchnode.com/docs/api/consent.md): Consent receipts: what a patient shared and whether it is active.
- [Sandbox API](https://finchnode.com/docs/api/sandbox.md): Simulate sessions and drive synthetic patients with sandbox keys.
- [Conformance API](https://finchnode.com/docs/api/conformance.md): Runs that test your integration against the sandbox.
- [Webhook events](https://finchnode.com/docs/api/webhook-events.md): Every FinchNode webhook event and the envelope they share.
- [Demo API reference](https://finchnode.com/docs/api/demo.md): The keyless demo API: synthetic records with no account.
- [MCP tools](https://finchnode.com/docs/api/mcp-tools.md): The authenticated MCP server's tools and the REST operation each mirrors.

## Products

- [Products index](https://finchnode.com/products.md): every FinchNode product with a first request, agent setup, reference, and boundaries.
- [Hosted Connect](https://finchnode.com/products/hosted-connect.md): One hosted link takes a patient from provider search to a signed consent receipt.
- [Records API](https://finchnode.com/products/records-api.md): Consent-filtered, normalized health records with stable IDs, cursor pages, and a change feed.
- [Consent Ledger and Webhooks](https://finchnode.com/products/consent-ledger.md): Versioned consent receipts and signed, retryable webhooks for every grant, revocation, and sync.
- [MCP for Agents](https://finchnode.com/products/mcp.md): Two Streamable HTTP MCP endpoints: a keyless synthetic demo and your consented records.
- [Public Demo API](https://finchnode.com/products/demo-api.md): Twelve named synthetic scenarios from two synthetic sources, with no account or API key.
- [Scenario Sandbox](https://finchnode.com/products/scenario-sandbox.md): Named synthetic patients and deterministic failure cases, on the public demo and inside your sandbox.
- [Conformance Suite](https://finchnode.com/products/conformance-suite.md): A scripted run that grades how your sandbox app handles consent, pagination, rate limits, and webhooks.

## Developer and machine-readable resources

- [Accountless demo OpenAPI 3.1](https://finchnode.com/demo-openapi.json)
- [Authenticated API OpenAPI 3.1](https://finchnode.com/openapi.yaml)
- [Live public demo API](https://api.finchnode.com/demo/v1)
- Public synthetic MCP server (Streamable HTTP, POST only, no key): `https://api.finchnode.com/demo/mcp`
- Authenticated MCP server (Streamable HTTP, POST only, Bearer sandbox or live key): `https://api.finchnode.com/api/mcp`
- [MCP registry listings: com.finchnode/health-records-demo and com.finchnode/health-records](https://registry.modelcontextprotocol.io/v0/servers?search=com.finchnode)
- Coding-agent plugin and skills (finchnode-developer): published locations follow.
- TypeScript and Python starter SDKs: published locations follow.
- [Full machine-readable FinchNode reference](https://finchnode.com/llms-full.txt)
- [Developer guide RSS feed](https://finchnode.com/feed.xml)
- [XML sitemap](https://finchnode.com/sitemap.xml)

## Technical guides

- [What we learned building patient-authorized FHIR connections across EHRs.](https://finchnode.com/blog/fhir-connections-across-ehrs-field-notes.md): Firsthand FinchNode engineering notes on endpoint discovery, SMART authorization, scopes, patient context, and source-specific FHIR behavior.
- [SMART on FHIR OAuth with PKCE in React and Node.js.](https://finchnode.com/blog/smart-on-fhir-oauth-pkce-react-node.md): Implement a SMART on FHIR standalone authorization-code flow with PKCE, state validation, discovery, and server-side token exchange.
- [Fetch patient data with a FHIR API: Patient, labs, conditions, and medications.](https://finchnode.com/blog/fhir-api-tutorial-patient-data.md): Fetch Patient, Observation, Condition, and MedicationRequest resources safely with FHIR R4 searches and server-provided pagination.
- [Epic and MyChart FHIR integration for patient-facing applications.](https://finchnode.com/blog/epic-my-chart-fhir-integration-guide.md): Understand Epic patient-facing standalone OAuth, organization endpoints, PKCE, testing boundaries, and FHIR data access.
- [Oracle Health FHIR integration: discovery, authorization, and tenant routing.](https://finchnode.com/blog/oracle-health-fhir-integration-guide.md): Build Oracle Health SMART integrations with tenant routing, discovery, patient context, scopes, and honest production validation.
- [How to normalize FHIR data across EHRs without losing the source.](https://finchnode.com/blog/normalize-fhir-data-across-ehrs.md): Design a source-aware normalization layer for FHIR resources without erasing provenance, codes, missing data, or lifecycle state.
- [FHIR Patient $everything: pagination, missing data, and production caveats.](https://finchnode.com/blog/fhir-patient-everything-guide.md): Use the FHIR Patient $everything operation safely with date filters, type filters, Bundle pagination, size limits, and fallback searches.
- [FHIR API error handling: retries, rate limits, and partial results.](https://finchnode.com/blog/fhir-api-errors-retries-rate-limits.md): Handle FHIR OperationOutcome errors, timeouts, rate limits, retries, partial sync, and idempotency without hiding data loss.
- [Patient authorization versus application consent in healthcare APIs.](https://finchnode.com/blog/patient-authorization-vs-app-consent.md): Separate EHR authorization from application-specific sharing consent, category limits, revocation, expiry, and deletion.
- [Build a longitudinal patient record with TypeScript.](https://finchnode.com/blog/longitudinal-patient-record-typescript.md): Aggregate source-aware FHIR records into a chronological patient timeline with stable identity, provenance, deduplication, and change cursors.
- [FHIR vs HL7 v2 vs C-CDA: a developer’s guide.](https://finchnode.com/blog/fhir-vs-hl7-v2-vs-ccda.md): Compare FHIR APIs, HL7 v2 event messages, and C-CDA clinical documents by transport, granularity, workflow, and implementation fit.
- [The 7 best FHIR interoperability platforms for health apps in 2026.](https://finchnode.com/blog/best-fhir-interoperability-platforms.md): Compare seven FHIR interoperability platforms by use case, data access model, workflow, and developer fit—including FinchNode, Redox, and Zus.
- [How one API connects your app to multiple EHRs.](https://finchnode.com/blog/one-api-connect-to-multiple-ehrs.md): Learn about multi-EHR API design and FinchNode’s free production access to patient-authorized records, plus a synthetic demo you can call without an account.
- [The easier way to get patient data from EHRs.](https://finchnode.com/blog/easier-access-to-patient-data.md): Compare direct FHIR integrations, patient-authorized APIs, and clinical data networks to find the simplest path to EHR data that respects the patient’s consent.

## Integration pages

- [Epic](https://finchnode.com/integrations/epic): Add patient-authorized Epic and MyChart record access to your health app through FinchNode’s hosted Connect flow and normalized API.
- [Oracle Health (Cerner)](https://finchnode.com/integrations/oracle-health): Add patient-authorized Oracle Health (Cerner) record access to your health app through FinchNode’s hosted Connect flow and normalized API.
- [athenahealth](https://finchnode.com/integrations/athenahealth): Add patient-authorized athenahealth record access to your health app through FinchNode’s hosted Connect flow and normalized API.
- [eClinicalWorks / healow](https://finchnode.com/integrations/eclinicalworks-healow): Add patient-authorized eClinicalWorks / healow record access to your health app through FinchNode’s hosted Connect flow and normalized API.
- [MEDITECH Expanse](https://finchnode.com/integrations/meditech): Add patient-authorized MEDITECH Expanse record access to your health app through FinchNode’s hosted Connect flow and normalized API.
- [Veradigm / Allscripts](https://finchnode.com/integrations/veradigm-allscripts): Add patient-authorized Veradigm / Allscripts record access to your health app through FinchNode’s hosted Connect flow and normalized API.
- [Medicare Blue Button 2.0](https://finchnode.com/integrations/medicare-blue-button): Add beneficiary-authorized Medicare coverage and claims access to your health app through FinchNode’s hosted Connect flow and normalized API.