Introduction
Most HR Tech and benefits platforms don't think of themselves as healthcare companies. But if your API transmits benefits enrollment data, insurance eligibility records, or dependent coverage information — you're handling electronic Protected Health Information (ePHI), and HIPAA applies to you directly.
According to the HIPAA Journal, the number of individuals affected by large healthcare data breaches soared 58% to more than 289 million in 2024 alone — nearly 85% of the US population — even as the count of reported breaches barely changed.
OCR enforcement isn't limited to hospitals, either. When MMG Fusion, a software company operating as a business associate, failed to secure its systems, OCR settled the investigation after a breach affecting approximately 15 million individuals.
The critical point: HIPAA violations aren't primarily caused by bad intent. They're caused by execution gaps — missing BAAs, over-permissioned tokens, raw ePHI in log files, encryption that was configured but not properly managed. This guide covers the specific controls that matter: authentication, encryption, audit logging, BAA requirements, and the implementation mistakes that turn compliant-looking APIs into enforcement targets.
TL;DR
- APIs transmitting benefits enrollment, eligibility, or dependent data handle ePHI — all three HIPAA Rules apply
- Business Associate Agreements (BAAs) must be signed before any ePHI is exchanged — not retroactively
- Core technical controls: TLS 1.2+ in transit, AES-256 at rest, OAuth 2.0 with scoped tokens, and tamper-evident audit logs
- The "minimum necessary" standard requires endpoints to return only the ePHI fields a given use case actually needs
- Most common failures: skipped BAAs, over-broad token scopes, raw ePHI in logs, missing breach notification procedures
What Makes an API HIPAA Compliant? The 3 Rules Every Developer Must Know
What Counts as ePHI in a Benefits API
HIPAA defines ePHI as any of 18 specified identifiers combined with health information, transmitted or stored electronically. For benefits developers, the identifiers most commonly present in API payloads include:
- Employee and dependent names
- Dates of birth and enrollment dates
- Social Security numbers
- Health plan beneficiary/member IDs
- Email addresses and IP addresses
- Internal employee IDs or opaque account numbers
When any of these appear alongside health coverage data — plan elections, coverage tiers, dependent relationships, insurance carrier IDs — the combination qualifies as ePHI. Benefits enrollment records, eligibility responses, and dependent coverage data all trigger HIPAA obligations. Platforms connecting to 60+ HRIS and carrier systems, as Bindbee does on behalf of its benefits platform customers, are handling ePHI at scale across every one of those connections.
The Privacy Rule: Minimum Necessary Access
The Privacy Rule governs who can use or disclose ePHI and under what conditions. For API developers, the operative requirement is the minimum necessary standard (45 CFR 164.502(b)): your API must make reasonable efforts to limit ePHI in every response to what's actually needed for the stated purpose.
In practice, this means:
- A benefits eligibility endpoint should not return a full health record
- Response schemas should be scoped per use case, not per authenticated user
- Role-based access policies must define which PHI categories each role can see
Bindbee implements this at the API layer through field-level scoping — customers define exactly which models and fields to sync, so downstream platforms receive only the ePHI their use case requires.
The Security Rule: Five Technical Safeguards
The Privacy Rule governs access policy. The Security Rule (45 CFR 164.312) governs the technical controls that enforce it — five safeguards that map directly to API architecture decisions:
| Safeguard | What It Requires at the API Layer |
|---|---|
| Access Control | Unique user IDs, least-privilege token scoping, automatic logoff |
| Audit Controls | Structured logging of every ePHI access with tamper-evident storage |
| Integrity | Mechanisms to detect improper alteration of ePHI |
| Authentication | Verified identity for every entity accessing ePHI |
| Transmission Security | TLS 1.2+ with HSTS; encryption for data at rest |
The Breach Notification Rule and BAA Requirement
A breach is any unauthorized acquisition, access, use, or disclosure of ePHI. It's presumed to be a breach unless a risk assessment demonstrates a low probability of compromise, which means the burden of proof falls on you. Business associates must notify the covered entity within 60 days of discovery.
Every vendor in your stack also needs a signed Business Associate Agreement (BAA) before any ePHI changes hands. Under 45 CFR 164.308(b), this covers your cloud provider, logging platform, error tracking tool, and analytics service. A missing BAA is an automatic HIPAA violation regardless of your technical controls.
The Center for Children's Digestive Health paid $31,000 for sharing PHI with a business associate for over a decade without a signed BAA. The retroactive agreement didn't cure the violation.
What You Need Before Building a HIPAA Compliant API
Preparation determines whether the controls you build are adequate or merely cosmetic. Don't write a line of code before completing three foundational steps.
Scope and Inventory
Map every endpoint, data flow, and integration point that touches ePHI. Identify which of the 18 HIPAA identifiers your API handles and in what context. This scoping exercise sets the level of rigor required — over-scoping wastes engineering resources, but under-scoping creates compliance gaps that OCR investigations will surface.
Vendor and Legal Readiness
Before integrating with any third-party system:
- Confirm each vendor offers a signed BAA with HIPAA-eligible infrastructure
- Designate a Privacy Officer — OCR expects documented evidence of this role
- Ensure your development team has completed HIPAA training with records to prove it
- Verify that cloud providers (AWS, Azure, GCP) have BAAs in place for the specific services your API uses
Bindbee supports private cloud deployment across AWS, Azure, and GCP, holds SOC 2 Type II and ISO 27001 certification, and runs independent third-party risk assessments annually — so benefits platforms building on top of Bindbee start with an audited infrastructure baseline rather than building one from scratch.
Threat Modeling
Run a STRIDE-based threat model against your API's data flow diagrams before development begins. The table below maps each STRIDE category to a concrete ePHI-specific risk:
| STRIDE Category | ePHI-Specific Threat Example |
|---|---|
| Spoofing | Forged OAuth tokens used to access benefits records |
| Tampering | Modifying enrollment data via an unsecured API endpoint |
| Repudiation | No audit trail when ePHI records are updated or deleted |
| Information Disclosure | ePHI exposed through verbose error messages or debug logs |
| Elevation of Privilege | Read-only user escalating access to write or delete ePHI |
OWASP ranks Broken Object Level Authorization (BOLA) as the #1 API security risk — meaning an authenticated user manipulates an employee ID parameter to access another person's benefits data. Every endpoint must enforce per-object authorization checks server-side, every time.
How to Build a HIPAA Compliant API: Step-by-Step Best Practices
Step 1: Enforce Strong Authentication and Role-Based Authorization
Implement OAuth 2.0 with OpenID Connect for all API authentication. Issue unique credentials per user and per integration — never use shared API keys on ePHI-handling endpoints.
Each token must be narrowed to the minimum access required. Scope tightly by integration type:
- A patient-facing app → read-only token scoped to that individual's records
- A benefits admin portal → write-scoped token limited to specific plan data it manages
- A carrier integration → token scoped to eligibility fields only, not full census records
Apply RBAC or ABAC at the API layer so authenticated users can only access the ePHI fields their role permits. Set strict token lifetimes and automatic session expiration.
Enforce MFA for all admin and developer access to production ePHI — the HHS 405(d) program explicitly recommends MFA for all remote access to ePHI systems.
Step 2: Encrypt ePHI in Transit and at Rest
In transit:
- Enforce HTTPS with TLS 1.2 minimum on all endpoints — NIST SP 800-52 Rev. 2 approves TLS 1.2 for federal information protection
- Disable TLS 1.0 and 1.1 entirely
- Implement HSTS to prevent protocol downgrade attacks
- Use certificate pinning for mobile API clients
- For legacy system integrations, use VPNs rather than public internet
At rest:
- Encrypt all ePHI with AES-256 for databases, object storage, and file systems
- Manage keys through a dedicated key management system (AWS KMS or an HSM)
- Document key rotation procedures — storing keys alongside encrypted data itself constitutes a HIPAA violation
- Never hardcode encryption keys in application code
Step 3: Build Tamper-Evident Audit Logs
Every API interaction involving ePHI requires a structured log entry capturing:
- Timestamp
- User/system identity
- Patient or record ID (opaque, not raw ePHI)
- Source IP and client app ID
- HTTP method, endpoint, and action outcome
Do not log raw ePHI fields — use opaque resource identifiers instead. An SSN or DOB appearing in a log file that a third-party monitoring vendor accesses without a BAA is itself a HIPAA violation, even if your core database is properly encrypted.
Store logs in append-only or cryptographically signed storage and centralize them in a SIEM. Configure real-time alerting on anomalies: repeated auth failures, bulk exports outside business hours, and access from unexpected IP ranges.
Retain all logs for a minimum of six years per 45 CFR 164.316(b)(2).
Step 4: Apply Data Minimization Across All Endpoints
Implement field-level whitelisting so each endpoint returns only the ePHI attributes its specific purpose requires. A scheduling endpoint has no business returning clinical history. A dependent eligibility check doesn't need an employee's full compensation record.
Apply these rules consistently across every endpoint:
- Never expose SSNs or member record numbers in URL paths — they appear in server logs and proxy caches. Use opaque, non-guessable resource IDs instead
- Use de-identified test data in all non-production environments — strip all 18 HIPAA identifiers before data enters development, staging, or analytics pipelines
- Establish a documented de-identification process; ensure no ePHI flows into third-party analytics without an explicit BAA
Key Parameters That Define HIPAA API Compliance
Four implementation variables determine whether your API actually meets HIPAA's requirements in practice:
Encryption Standard and Key Management
HIPAA doesn't name a specific algorithm, but HHS guidance points to NIST standards — making AES-256 at rest and TLS 1.2+ in transit the practical minimum. Using weaker encryption (DES, RC4, TLS 1.0) creates a gap OCR audits will surface.
Properly encrypted PHI qualifies as "secured" under the Breach Notification Rule, giving you the safe harbor from breach notification penalties.
Poor key management — hardcoded keys, no rotation policy, keys stored alongside encrypted data — is treated as a HIPAA violation independent of encryption quality.
Why Token Scope Determines Breach Exposure
Broad OAuth scopes violate the minimum necessary principle even when encryption is strong. Compare these two approaches:
- ❌ Incorrect: Single token granting read/write access to all employee records for a third-party wellness app
- ✅ Correct: Token scoped to read-only access on
benefits.eligibilityfor the authenticated employee only
If a compromised third-party app holds a broad token, the scope of a potential breach — and your HIPAA penalty exposure — expands dramatically. Scope every token to the narrowest set of permissions that still allows the integration to function.
Audit Log Completeness and Integrity
HIPAA requires logs that are complete, tamper-proof, and accessible for review. Logs missing user identity, lacking timestamps, or stored in mutable formats fail the audit control requirement regardless of your other safeguards.
Incomplete logs also convert a potential violation into a confirmed one during OCR investigations; they prevent you from fulfilling individual rights requests for an accounting of ePHI disclosures.
BAA Coverage Completeness
Technical controls alone don't close every gap — vendor coverage has to match. A BAA gap with any vendor that handles ePHI is a standalone HIPAA violation, independent of your technical controls. This includes:
- Cloud infrastructure providers
- Logging and monitoring services
- Error tracking tools
- Analytics platforms that process API traffic
BAAs must be in place before ePHI flows — not retroactively. The CCDH enforcement action confirmed that retroactive BAAs don't remedy years of non-coverage.
Common Mistakes When Building HIPAA Compliant APIs
Treating compliance as a one-time build. OCR expects periodic risk assessments, updated policies, staff training records, and documented incident response testing. An API that passes a compliance review at launch can fall out of compliance within months if no governance process exists.
Allowing raw ePHI in error messages, logs, or URL parameters. This is one of the most common and exploited API-layer vulnerabilities. An employee SSN appearing in a server log that a third-party monitoring tool reads — even briefly — can constitute a disclosure if that tool lacks a BAA.
Underestimating the HIPAA scope of HR and benefits integrations. Many HR Tech and benefits platforms assume HIPAA only applies to clinical EHR data. But any API exchange combining employee identifiers with benefits election data qualifies as ePHI handling — regardless of whether a hospital or clinic is involved.
For platforms connecting to 60+ HRIS and carrier systems, maintaining HIPAA controls per integration creates a growing engineering and compliance burden. Each new system connection requires its own security review, BAA verification, and ongoing maintenance as upstream APIs evolve.
A SOC 2 Type II and HIPAA-compliant unified API layer like Bindbee addresses this directly: it normalizes data across HR and benefits systems through a single secure integration, removing the need to manage controls for each connection independently. Bindbee customers report cutting integration time from 8–12 weeks to under 48 hours, with no ongoing maintenance burden per integration.
Frequently Asked Questions
Are APIs HIPAA compliant?
APIs are not inherently HIPAA compliant — compliance depends entirely on whether the API handles ePHI and whether it implements the required technical safeguards (encryption, access controls, audit logging) and administrative controls like BAAs and risk assessments. An API that processes only de-identified data has no HIPAA obligations.
Is an API gateway HIPAA compliant?
An API gateway can be configured to support HIPAA compliance by enforcing authentication, rate limiting, TLS, and centralized logging — but the gateway itself isn't inherently compliant. It must be deployed within a HIPAA-aligned architecture, and the infrastructure provider hosting it must sign a BAA.
Can an API gateway do authorization?
Yes. API gateways can enforce authorization through OAuth 2.0 token validation, scope verification, and role-based policy enforcement at the gateway layer — offloading this logic from individual microservices and centralizing it for easier auditing and policy updates.
Can an API call be traced?
Yes — every API call touching ePHI must be traced through structured audit logging. Each request should capture a timestamp, user identity, resource accessed, action taken, and source IP, retained in tamper-evident storage for six years.
How do you document HIPAA compliance?
Core documentation includes a current risk assessment, written Security and Privacy Rule policies, employee training records, a BAA inventory, and incident response procedures. OCR expects all of it updated whenever systems or processes change.
Is AES-256 HIPAA compliant?
AES-256 meets the encryption standard for ePHI at rest under HIPAA guidance. The regulation doesn't mandate a specific algorithm by name, but requires adherence to current NIST standards — AES-256 satisfies that requirement.
