HIPAA and the Knack API

What You'll Learn

This article covers what you need to know about using the Knack API on a HIPAA plan. The API is a powerful tool for accessing and managing your data, but it also introduces risks that you're responsible for managing. This article explains those risks and how to handle them.

Your Responsibility

The Knack API gives you direct access to your app's data. That includes any PHI stored in your tables. Knack has no ability to limit or enforce restrictions on which data can or cannot be accessed through the API.

You are solely responsible for any API usage that leads to PHI breaches or security compromises.

This is not a platform limitation you can work around — it's how APIs work. The API returns data based on what you request, and it's up to you to make sure your requests, your code, and your integrations handle that data appropriately.

Use the HIPAA API Endpoint

Once your account is migrated to the HIPAA environment, all API calls must be sent to:

usgc-api.knack.com

Calls made to api.knack.com will not work after migration. If you have existing integrations, custom code, or third-party connections that use the standard endpoint, you'll need to update them.

⚠️

Update your integrations. Any custom API code, Zapier connections, or third-party tools that call the Knack API must be pointed to usgc-api.knack.com after your account is migrated.

Field-Level Access Limitations

The Knack API does not support field-level access restrictions. When you request a record, the API returns all fields that the authenticated user has access to. You cannot exclude specific fields from the response at the API level.

This means:

• If a table contains both clinical notes and billing codes, an API request for records in that table returns both — even if the integration only needs billing codes
• You're responsible for filtering out unnecessary fields in your code before passing data downstream
• The Minimum Necessary Rule still applies: only use and forward the fields you actually need

Never Expose API Keys in Client-Side Code

Your API key is the credential that grants access to your data. If it's exposed, anyone who has it can read, write, update, and delete records in your app.

• Don't include your API key in client-side JavaScript. Browser-based code is visible to anyone using developer tools.
• Use view-based API requests for any operations that run in the browser. View-based requests are scoped to the logged-in user's permissions and don't expose your API key.
• Store API keys server-side in environment variables or a secrets manager. Never hard-code them in your codebase.

Rotate API Keys Regularly

API keys should be rotated at least annually. Treat your API key like a password — if it's been in use for a long time, if someone who had access to it leaves your organization, or if you suspect it may have been compromised, rotate it immediately.

Third-Party Services and the API

If you use the API to send data to third-party services (analytics platforms, email providers, reporting tools, etc.), you need to verify that those services handle PHI appropriately.

• Before sending data to any external service via the API, confirm that the service is HIPAA compliant and that you have a BAA in place with them
• Knack cannot guarantee the security of your data once it leaves the Knack environment
• If you're emailing, exporting, or transmitting PHI through the API to a third party, the security of that data is entirely your responsibility

This also applies to Flows. If a Flow sends data from your Knack app to an external service, the same rules apply — verify compliance before connecting.

For more on third-party tools, see Flows and Third-Party Compliance.

Summary

Next Steps

• Authentication Best Practices — Secure login access to your app
• Flows and Third-Party Compliance — HIPAA considerations for automations and integrations
• Migrating to the HIPAA Environment — What changes when your account moves to the HIPAA infrastructure