# Handling patient data

> Everything FinchNode returns about a patient is health data, so keep it out of places it doesn't belong.

These are the practices FinchNode's API is built around. Your own legal and compliance obligations depend on who you are and what you build, so review them with your team.

## Store keys and secrets

- Call FinchNode only from your server. Never put a key in a browser, mobile app, or prompt.
- Keep keys and webhook secrets in a secret manager. Rotate them if they leak.
- Use [delegated agent credentials](/docs/ai-agents/agent-credentials) for REST agents that need one patient.

## Keep patient data out of these places

- **URLs.** No names, emails, record values, or subjects in query strings. `externalId` is for an opaque ID.
- **Logs and error trackers.** Log request IDs, event IDs, and status codes. Not record bodies or subjects.
- **Analytics and browser storage.** Keep patient data out of both.
- **Model providers.** Check that your agreement with the provider covers health data before sending records.

## Store what you import

- Encrypt it at rest.
- Keep only the categories you use, for as long as your retention period says.
- Keep each record's `source` and `syncedAt` so you can say where it came from and how current it is.

## Stop when access ends

- On `410 consent_inactive`, stop reading and apply your retention policy.
- When one receipt is revoked or expires, remove that source's records.
- On `deletion.requested`, delete what you hold for that subject.

See [Consent, revocation, and deletion](/docs/records/consent-revocation-deletion).

## Use test data

Use the sandbox and the demo API for development and tests. Label synthetic data as synthetic wherever it appears, and never copy production records into a test environment.