HIPAA-compliant chat APIs for developers

A chat API can carry PHI only when the provider signs a business associate agreement (BAA) that covers the specific service and plan you use, and you configure and operate it correctly. No badge on a pricing page changes that. This page gives you a checklist to run before any PHI touches a chat provider, explains where the vendor's responsibility ends and yours begins, and routes you to the sourced comparisons.

What "HIPAA-compliant chat API" means in practice

There is no HIPAA certification for APIs, SDKs or chat platforms. HHS does not certify software. What exists is a chain of agreements and controls: a signed BAA, a configuration that matches what the BAA covers, and the customer's own policies and procedures. Compliance depends on all three. A vendor that says "HIPAA compliant" in marketing copy has told you nothing until you have read the BAA and the list of covered services.

Here is how the roles usually fall in a typical app:

• Covered entity: the clinic, health system or health plan whose patients' messages are in the chat.
• Business associate: the healthtech company building the app on the clinic's behalf, if it creates, receives, maintains or transmits PHI for the clinic.
• Subcontractor business associate: the chat API vendor, when the app's backend sends PHI to it. The business associate needs a BAA with that subcontractor, and the vendor is bound by the same kind of obligations downstream.

If you are building for your own clinic, you are the covered entity and the API vendor is your business associate. The regulatory text sits in 45 CFR 160.103 (definitions), 164.502(e) (disclosures to business associates) and 164.504(e) (BAA contents). Under 160.103 a business associate is a person who, on behalf of a covered entity, creates, receives, maintains or transmits protected health information, and the definition includes a subcontractor that does so for another business associate. Under 164.504(e)(2) the contract must set permitted uses and disclosures, require safeguards and compliance with Subpart C, require reporting of non-permitted uses and disclosures including breaches of unsecured PHI, and require subcontractors to agree to the same restrictions. (ecfr.gov)

This page does not issue vendor verdicts and is not legal advice. Vendor-by-vendor entries live on hipaacompliant.wiki. If you are still deciding whether you need an API at all, or a different kind of chat, start with which kind of chat you need under HIPAA.

Checklist: what to verify before sending PHI to a chat API

Work through these in order. Stop at the first item you can't answer from the vendor's own published documents.

1. The BAA

• Is a BAA offered at all? Look for a published BAA page or a documented request process, not a sales-call promise.
• On which plans? Many vendors restrict a BAA to higher tiers or enterprise contracts. A free or starter plan may not be covered even if the same product is.
• For which services? Messaging is one service. File storage, push notifications, video, moderation, translation and AI features may each be inside or outside the agreement. Write down the exact services your app will call and match them one by one against the BAA's scope.

2. Exclusions

Read the vendor's published exclusions: features, add-ons, beta products, regions or deployment options the BAA does not cover. A typical trap is a clinic enabling an AI summarization or auto-moderation add-on that sits outside the BAA while the core messaging service is inside it. If the vendor publishes no exclusions list, record that and ask in writing.

3. Technical controls

Check what the vendor publishes, and quote it as vendor-published, for:

• Encryption in transit and at rest
• Access controls for your own staff and the vendor's staff
• Audit logs: what is logged, how long it is kept, whether you can export it
• Data retention and deletion: defaults, configurable windows, whether deletion reaches backups
• Data residency options

Twilio requires HTTPS for HIPAA setups, encrypts voice recordings at rest by default, keeps Audit Events API logs for 30 days (400 days with an Editions purchase), logs HIPAA console users off after 15 minutes of inactivity, and publishes no residency claim for chat. Sendbird states TLS 1.3, optional AES256 encryption for files in messages, and claims "End-to-end encryption and TLS in transit" and "Full audit logs"; its pricing page says messages are kept six months, with longer retention only on Enterprise, and its region count is inconsistent (9 AWS regions on the pricing page, "eleven global regions" with only 9 listed on the features page). Stream encrypts data at rest with Cloud KMS keys it controls and in transit with TLS, offers no native end-to-end encryption, runs on Google Cloud, keeps messages indefinitely by default with configurable retention from 24 hours to 5 years (deletion does not change existing backups), and offers message audit logs and a dedicated region stack only on Enterprise. PubNub lists retention tiers of 7 days, up to 6 months and unlimited, says data can be locked to US-only data centres, and says audit logs are built in. (twilio.com)

4. Subprocessors and third parties

A chat API rarely runs alone. Ask for the subprocessor list and look for push notification gateways (Apple and Google both sit in the path of a mobile push), analytics, logging, email or SMS relays, and AI or moderation services. Each is a place message content or metadata could land. Confirm which of them the vendor's BAA covers.

5. Support and incident terms

Read the breach notification terms in the BAA as the vendor publishes them: who is notified, how fast, and through which channel. Your own contract with a covered entity may demand a shorter notice window than the vendor gives you. If so, you carry the gap. Twilio and Sendbird do not publish their BAA breach-notification terms; their BAAs are available only on request, and Twilio's comes through an account manager. Stream's security page, which is not BAA text, says it notifies customers as soon as possible by email and phone call and sends communication within 72 hours of becoming aware. Supabase's HIPAA guide says only that it must report breaches to the customer, with no time or channel stated. (getstream.io)

Where the BAA stops and your responsibility starts

A signed BAA covers the vendor's handling of data inside its service. It says nothing about how your app uses that service. These are yours:

• Authentication and authorization. The vendor can enforce that a token is valid. Only your backend knows whether this user may read that conversation. A patient must never be able to guess a channel ID and join another patient's thread.
• Tenant separation. If one app serves several clinics, you define and enforce the boundaries between them.
• Message content. Whether users can paste a diagnosis, upload a photo of a wound or attach a lab PDF is a product decision you make.
• Client-side storage. Cached messages on a phone, a web app's local storage, and screenshots in crash reports all live outside the vendor's boundary.

Push notifications and webhooks. A push payload travels through Apple's and Google's services. A webhook travels to whatever endpoint you configure, over whatever logging sits in front of it. A notification reading "Your lab results for HIV panel are ready" is a disclosure to services your BAA chain may not include. Use a generic payload such as "You have a new message," and fetch content after the user opens the app and authenticates.

Logging, error tracking and analytics SDKs. Many crash reporters and session-replay tools capture request bodies, screen contents or breadcrumbs. If message text is in the request, it can end up in a tool with no BAA. Review what each client and server SDK captures, and scrub message fields before they leave your process.

Retention and deletion. Decide what you configure and what the vendor does by default. If the default is indefinite retention and your policy says seven years for the medical record but thirty days for transient chat, the setting is yours to change, and yours to prove you changed.

Types of chat APIs and how HIPAA applies to each

Hosted chat platforms and messaging APIs. This covers chat-as-a-service, in-app chat APIs and SMS APIs. If the vendor offers a BAA, it names covered services and often limits plans. Your work is matching your usage to that scope and configuring the controls above.

Backend-as-a-service and cloud platforms. Here chat is something you assemble from general services such as a database, a realtime layer, functions and storage. A cloud BAA typically covers only the services the provider lists as eligible. Using a service that is not on the list for chat data breaks the chain even though the platform name appears on a BAA. For example, Google Cloud's HIPAA page lists Firestore, Cloud Storage, Pub/Sub, Cloud Run and Vertex AI, and the word "Firebase" does not appear on it. Twilio publishes a HIPAA-eligible products and services list. AWS publishes a HIPAA eligible services reference. Supabase publishes no service list and instead uses "HIPAA projects" under its BAA. (docs.cloud.google.com)

Self-hosted and open-source chat. The software license is not a BAA, and the software authors are not your business associate. The hosting provider needs a BAA covering the infrastructure, and you carry patching, backups, access review, logging and incident response. Open-source code is not compliant by itself; the way you run it is what counts. Details are in open-source chat under HIPAA.

UI kits and SDKs. A client library is code in your app. It does not change who holds the data. The question is which backend the SDK talks to, whether that backend is covered by a BAA, and what the SDK writes to device storage, logs or analytics. Client-library specifics are collected in HIPAA-compliant chat SDKs.

Providers with a BAA: how to read the comparison

The full table is at chat API providers with a BAA compared. It is sorted by facts: first the verdict, then the plan the BAA applies to, then price. It is not a ranking, and no row is described as better than another. This page's teaser follows the same order.

Every verdict uses one wording: BAA available on for . Nothing stronger is written, and where a vendor publishes nothing on a point, the cell says so. Prices are shown as the vendor lists them, and any non-USD currency is marked.

Provider	BAA available on (plans)	For (services)	Published exclusions	Price	Source
Twilio	Security Edition or Enterprise Edition (HIPAA Accounts) (twilio.com)	Conversations (classic) for chat, SMS, MMS and group texting, including media. Programmable Chat (end-of-life 25 Jul 2022) and Frontline (end-of-life 30 Sep 2026) are also listed but retired. (twil.io)	Not eligible: WhatsApp, Autopilot bots, Conversation Orchestrator, the Conversations channel of Conversation Intelligence (classic) and the newer Conversation Intelligence, and AI Assistants via Conversation Relay. Chat must use private channels only. (twil.io)	Not published (contact sales) (twilio.com)	https://www.twilio.com/docs/iam/twilio-editions/hippa (twilio.com)
Stream	Elevate and Enterprise only (HIPAA is unavailable on Build and Start) (getstream.io)	Chat (getstream.io)	Not stated on the pricing or security pages	Elevate: $599/mo billed annually or $675 monthly (10K MAU); Enterprise: custom (getstream.io)	https://getstream.io/chat/pricing/ (getstream.io)

Per-vendor entries with fuller context are kept at hipaacompliant.wiki and are not repeated here.

Architecture patterns that reduce PHI exposure

The less PHI the chat provider holds, the smaller the scope of your BAA review and the smaller the damage from any single mistake.

• Keep PHI out of identifiers. Channel names like dr-lee-jane-smith-knee-surgery, user display names with full patient names, URLs with patient IDs, and custom metadata fields are all searched, logged and cached more widely than message bodies. Use opaque IDs such as ch_8f3a91.
• Store minimal identifiers in the provider; keep clinical data in your system. A message can say "Your pre-op instructions are ready" with a reference ID, and your app resolves it against your own database after authorization. The chat vendor then holds a pointer, not a chart.
• Issue tokens server-side. Your backend authenticates the user, decides which channels they may access, and mints a short-lived token. Never ship an API secret in a mobile app or browser bundle. Per-user authorization checks belong on your server, not in client code.
• Treat attachments separately. Decide whether files go through the chat vendor's storage (and whether that service is inside the BAA) or through your own storage with signed, expiring links.
• Plan deletion up front. Build the delete-and-export path before launch, because a patient or covered-entity request will arrive after.

The full patterns, with diagrams and failure cases, are in architecting chat that touches PHI.

Build, buy or self-host: a decision path

Four questions usually decide it:

1. Team size. Two developers rarely have capacity to run, patch and monitor a realtime messaging cluster.
2. PHI volume. A pilot with one clinic and a few hundred threads has different risk than a national telehealth app.
3. Audit-log needs. If a covered-entity customer requires exportable access logs per conversation, check whether the vendor publishes that capability or whether you must build it.
4. Tolerance for operating infrastructure. On-call rotations, backups and restore tests are part of self-hosting.

What a BAA-backed hosted API saves: you inherit the vendor's infrastructure operations, patching, and the contractual obligations of a subcontractor business associate for the covered services. What it doesn't save: authorization logic, payload design, SDK and logging review, retention configuration, your own risk analysis and staff training.

What self-hosting adds: a BAA with the hosting provider, patch and vulnerability management, encrypted backups with tested restores, periodic access review, and your own incident response. You gain control over residency and data flow; you also own every gap.

Some needs fall outside this page's rules. If the feature is a chatbot or summarizer, the questions about model providers and training data are different; see AI chat and PHI: what HIPAA allows. If it is a live consult, see HIPAA-compliant video chat. If you want a widget on a clinic website for appointment questions, see HIPAA-compliant live chat for healthcare websites. For internal messaging between clinic staff, a different category with its own page, go to chanty.health.

Sources and last verified

FAQ

Is there a HIPAA-certified chat API?

No. HHS does not certify chat APIs or any other software. A vendor can offer a BAA for specific services and plans, and can publish security documentation, but a "certified" label is not a recognized HIPAA status. Read the BAA scope instead.

Do I need a BAA with a chat API provider?

If PHI will pass through the provider's service, yes. A business associate or covered entity needs a BAA with each vendor that creates, receives, maintains or transmits PHI on its behalf. If the vendor won't sign one for the service and plan you use, don't send PHI through it.

Can I send PHI through a chat API if the provider offers a BAA?

Only for the services and plans the BAA names, and only with your own configuration and policies in place. A BAA is a necessary condition, not a sufficient one. You still need authorization, minimal payloads, controlled logging and a retention policy.

Does a BAA cover every feature of the API, such as push notifications, file uploads or AI add-ons?

Not by default. Scope is set by the vendor's agreement, and features such as push, file storage, moderation or AI add-ons may be listed, excluded or simply not mentioned. Match each feature you use against the BAA and the vendor's published exclusions. Twilio lists Conversations (classic) media as eligible, excludes its bot and AI features, and does not mention chat push (only Verify Push, a sign-in feature, is listed). Sendbird documents file encryption but does not publish whether its BAA covers files, push or AI. Stream includes push on all plans with no HIPAA statement, and its AI features carry terms letting Stream use the data to improve its models. CometChat puts AI smart replies and summaries in the same plan as HIPAA/BAA without stating coverage. (twil.io)

Is an open-source chat library HIPAA compliant?

Not by itself. An open-source library has no BAA and no one signing obligations. Compliance depends on where you host it (with a hosting BAA), how you secure and patch it, and your policies. See open-source chat under HIPAA for the details.

What should never go into push notification payloads or chat metadata?

Don't put patient names, diagnoses, medication or test names, appointment reasons, record numbers or message text in push payloads. The same applies to channel names, display names, URLs and custom metadata fields. Use generic text like "You have a new message" and opaque identifiers, and load content after the user authenticates.

Who is responsible for HIPAA compliance, the API vendor or the developer?

Both, for different parts. The vendor is responsible for the services and obligations its BAA covers. The developer or covered entity is responsible for everything outside that: user authentication, authorization, payload design, third-party SDKs, retention settings, risk analysis and staff policies. A BAA moves some obligations to the vendor; it doesn't move yours.

• HIPAA-Compliant Chat API Providers: Which Offer a BAA, and How to Choose
• HIPAA-Compliant Chat SDKs: What to Check Before You Build
• Open-source chat under HIPAA: what you can use and what you still owe
• Architecting a HIPAA-Compliant Chat API for Telehealth and Text Chat