Real-Time Pass-Through API vs Sync and Cache: The 2026 HIPAA Guide

If your enterprise deal just stalled because the prospect's InfoSec team flagged your integration middleware for caching patient data, this is the architectural breakdown you need. The choice between a real-time pass-through API vs sync and cache for HIPAA compliance dictates whether your enterprise deals close or die in security review.

A real-time pass-through API processes data entirely in transit without persisting payloads, while a sync-and-cache API polls, stores, and serves normalized copies from its own database. Under HIPAA regulations, that architectural distinction determines whether your integration vendor is classified as a Business Associate—and whether you need a Business Associate Agreement (BAA), a sub-processor disclosure, and months of additional security scrutiny.

The reality of building integrations in the healthcare sector is unforgiving. When you sell to hospitals, clinics, or enterprise healthcare providers, your architecture is scrutinized under a microscope. Traditional integration middleware relies on a sync-and-cache model, expanding your compliance footprint and creating unmanaged shadow data.

This guide breaks down the compliance mechanics of both architectures, explains exactly where the HIPAA conduit exception applies (and where it doesn't), and walks through the technical trade-offs that engineering leaders and product managers must evaluate before choosing an integration strategy for healthcare SaaS.

The $7.4 Million Problem: Why Healthcare Integrations Fail Security Reviews

Healthcare data breaches averaged $7.42 million per incident in 2025, and healthcare has been the costliest sector for breaches for 14 consecutive years, according to IBM's annual Cost of a Data Breach Report. The containment timeline averaged 279 days—more than nine months of exposure before the organization even fully understands what happened.

Those numbers matter directly to your integration architecture. IBM's 2025 findings highlight how fast-moving threats exploit third-party vendors and unsecured environments, with healthcare seeing millions of records containing PII and PHI stolen from overlooked systems.

Here is the scenario that plays out in every upmarket healthcare deal: your sales team closes a six-figure contract with a hospital network or digital health platform. Procurement sends over a Standardized Information Gathering (SIG) Core questionnaire. Somewhere in that massive spreadsheet, Question #47 acts as a tripwire: "Does any third-party sub-processor store, cache, or replicate our data?"

If you need an integration tool that doesn't store customer data but your current vendor uses a sync-and-cache model, you have to answer "yes." That single affirmative answer triggers a cascade of follow-up scrutiny regarding encryption standards, data residency, retention policies, breach notification timelines, and BAA coverage. Deals don't just slow down—they die entirely because the integration vendor refuses to sign a BAA or cannot prove strict data isolation.

The root cause is architectural. Your choice between a pass-through and a sync-and-cache integration model isn't just a performance trade-off. It is a compliance decision with seven-figure consequences.

Sync and Cache Architecture: The Hidden HIPAA Liability

To understand why enterprise security teams reject traditional unified APIs, you have to look at how they actually move data.

A sync-and-cache unified API is an integration pattern where a middleware platform continuously polls upstream third-party APIs on a schedule, retrieves data in large batches, normalizes the payloads into a common schema, and stores that data persistently in its own managed database. When your application queries the unified API, it reads from that cached copy—not from the source system.

This is the dominant architecture for unified APIs that advertise fast response times and offline query capabilities. It works well for non-regulated data. For healthcare, however, it creates a massive compliance landmine.

Why Cached ePHI Makes Your Vendor a Business Associate

HHS guidance is explicit: Cloud Service Providers (CSPs) that provide cloud services involving creating, receiving, or maintaining ePHI meet the definition of a business associate, even if the CSP cannot view the ePHI because it is encrypted and the CSP does not have the decryption key. The conduit exception is limited to transmission-only services.

A sync-and-cache API does not merely transmit Electronic Protected Health Information (ePHI). It receives, normalizes, and maintains it in a database. That is textbook Business Associate territory. The consequences include:

• You must execute a comprehensive Business Associate Agreement (BAA) with the integration vendor before any ePHI flows through their system.
• The vendor must implement strict HIPAA Security Rule safeguards, conduct risk analyses, and report breaches.
• Oregon Health & Science University paid $2.7 million after an investigation revealed that ePHI had been stored on a cloud platform without a BAA.
• Your vendor appears as a sub-processor on every security questionnaire, expanding your compliance surface area.

The Shadow Data Problem

Sync-and-cache architectures create what security teams call shadow data—normalized copies of sensitive records that exist on a third-party's infrastructure, outside your direct control. You do not manage the encryption keys. You do not control the retention schedule. You cannot guarantee deletion when an integrated account is disconnected.

For healthcare SaaS, this shadow data problem is particularly toxic. If your integration vendor stores a cached copy of employee health records from a customer's HRIS, and that vendor suffers a breach, your customer's patients or employees are affected—and your organization is caught in the blast radius.

flowchart LR
    A[Your App] -->|API Call| B[Sync & Cache<br>Unified API]
    B -->|Scheduled Poll| C[Upstream API<br>e.g. Workday / Epic]
    B -->|Stores ePHI| D[(Vendor's<br>Database)]
    D -.->|Shadow Data<br>Exists Here| E[Compliance<br>Liability]
    style D fill:#ff6b6b,color:#fff
    style E fill:#ff6b6b,color:#fff

The diagram above illustrates the fundamental flaw. The middleware database acts as a persistent man-in-the-middle. It holds customer data hostage, increasing the surface area for a potential breach and violating the core security principle of data minimization.

Real-Time Pass-Through APIs: Processing Data in Transit

The alternative to building a shadow database is processing data entirely in transit.

A real-time pass-through API acts as a stateless proxy. When your application makes a request, the middleware immediately routes that request to the upstream third-party API in real time, transforms the response in memory using expression-based mapping (e.g., JSONata), and returns the normalized result to your application. No payload data is written to disk. No database stores a copy of the response.

This is the architecture Truto utilizes. When a request hits the Truto zero-storage unified API, the system looks up the integrated account, securely retrieves the necessary OAuth tokens from an encrypted vault, and fetches the resource directly from the provider. Once the response is delivered to your application, the data ceases to exist on Truto's infrastructure.

The key architectural properties include:

• No data at rest: Customer payload data is processed entirely in memory during transit. Once the response is returned, the data is gone.
• Real-time freshness: Every response reflects the current state of the source system. No stale cache. No sync lag.
• Smaller compliance footprint: Without persistent ePHI, the integration layer's HIPAA exposure is fundamentally different from a sync-and-cache model.

flowchart LR
    A[Your App] -->|Real-Time Request| B[Truto Pass-Through<br>Stateless Proxy]
    B -->|Direct API Call| C[Upstream API<br>e.g. Epic / HRIS]
    C -->|Raw Response| B
    B -->|In-Memory<br>Transform| A
    style B fill:#51cf66,color:#fff

Where the Conduit Exception Actually Applies

The HIPAA Conduit Exception is narrow and excludes an extremely limited group of entities from having to enter into business associate agreements. The Rule applies to entities that transmit PHI but do not have persistent access to the transmitted information and do not store copies of data. They simply act as conduits through which PHI flows.

A pass-through API that truly processes data only in transit—without logging payloads, without caching responses, and without writing ePHI to any persistent store—has a much stronger argument for conduit-like treatment. But be careful: vendors that are often misclassified as conduits include email service providers, cloud service providers, and messaging services. These are NOT considered conduits and all must enter into a BAA.

The distinction is surgical. If the integration layer touches ePHI in any persistent way—logging request bodies, storing webhook payloads, caching responses in a database—the conduit exception evaporates. Temporary storage that occurs only as part of routing or delivery generally fits the conduit exception. Once storage extends beyond transient transmission, conduit status ends and business associate obligations apply.

Conduit Exception: Plain-Language Decision Flow

Think of the conduit exception like the postal service. A mail carrier moves your envelope from sender to recipient. They don't open it, photocopy it, file a copy in a warehouse, or hold it for later analysis. If the carrier did any of those things, they would no longer be a conduit - they would be a records custodian.

Apply the same logic to your integration vendor. Ask the following questions in order. A single "yes" to questions 2 through 5 disqualifies the vendor from conduit status and requires a BAA with full Business Associate obligations.

flowchart TD
    A["Does the vendor's traffic<br>ever include ePHI?"] -->|No| B[No BAA needed]
    A -->|Yes| C["Does the vendor persist<br>request or response payloads<br>to disk?"]
    C -->|Yes| D["NOT a conduit<br>BAA required with full<br>Business Associate obligations"]
    C -->|No| E["Does the vendor log ePHI<br>in observability tooling<br>(request/response bodies)?"]
    E -->|Yes| D
    E -->|No| F["Does the vendor queue<br>failed requests for retry<br>in durable storage?"]
    F -->|Yes| D
    F -->|No| G["Does the vendor cache<br>inbound webhook payloads<br>before forwarding?"]
    G -->|Yes| D
    G -->|No| H["Conduit-eligible pattern<br>Consult counsel;<br>most orgs still sign a BAA<br>for defense in depth"]

The practical takeaway: even if you architect a pure pass-through integration layer, the conservative posture in 2026 is to execute a BAA anyway. The BAA is cheap. The pass-through architecture is what actually reduces your risk exposure under that BAA.

Honest Trade-Offs of Pass-Through Architectures

Pass-through APIs are not magic. They come with real engineering constraints that you should evaluate honestly:

For healthcare use cases where compliance is a hard requirement, the latency trade-off is usually acceptable. A 500ms slower API call is a minor engineering problem. A $7.4 million breach is not.

Data Flow and Responsibility Map

One of the most useful artifacts you can produce for a healthcare InfoSec review is a clear responsibility boundary diagram. It shows exactly which party holds ePHI, which party holds credentials, and which party is on the hook for each compliance control. Here is what that map looks like for a pass-through integration:

flowchart TB
    subgraph customer ["Your HIPAA-Compliant Environment (Covered Entity or BA)"]
        A["Your App<br>Data Controller"]
        Q[("Your Audit Log<br>encrypted at rest")]
        R[("Your Retry Queue<br>if 429 handling needed")]
    end
    subgraph truto ["Integration Layer (Transient Processor)"]
        B["Stateless Proxy"]
        V[("Encrypted Token Vault<br>OAuth tokens only")]
    end
    subgraph provider ["Upstream Provider (System of Record)"]
        C["EHR / HRIS / CRM API"]
        D[("Source Database<br>ePHI at rest")]
    end
    A -->|"Request + bearer token"| B
    B -->|"Token lookup"| V
    V -->|"Refreshed OAuth token"| B
    B -->|"Provider-native request"| C
    C -->|"Response payload"| D
    C -->|"Response payload"| B
    B -->|"Normalized response<br>in-memory transform"| A
    A -->|"Payload logged locally"| Q
    A -->|"Retries queued locally"| R

And here is the responsibility map you can hand to legal, procurement, or an auditor:

The pattern in this table is what makes the conversation with an InfoSec reviewer short. Every row where the integration layer says "none" or "metadata only" is a control you do not have to inherit, audit, or defend.

How Truto Handles Rate Limits and Retries (Without Caching)

A common engineering objection to pass-through architectures is the management of rate limits. "If you are not caching data, how do you handle rate limits from upstream APIs?"

This is a critical question for healthcare data pipelines where you might be pulling records across dozens of connected accounts. Traditional sync-and-cache tools mask this problem. They absorb rate limit errors by placing your requests into a persistent queue, applying exponential backoff, and retrying the request later.

The problem? A persistent queue is a database. If an integration tool queues a POST request containing patient data to handle a retry, that ePHI is now stored at rest on their servers. The zero data retention promise is broken, and a hidden data-in-flight vulnerability is created.

Truto takes a radically different, highly deterministic approach. Truto does not retry, throttle, or apply backoff when an upstream API returns a rate-limit error (HTTP 429).

The 429 response passes directly back to you, the caller. No request is silently queued. No retry loop runs on Truto's infrastructure. No ePHI sits in a buffer waiting to be reprocessed.

Instead, Truto normalizes the chaotic, provider-specific rate limit information into standard IETF headers. Upstream APIs express rate limits in wildly inconsistent ways—Salesforce uses Sforce-Limit-Info, HubSpot returns X-HubSpot-RateLimit-* headers, and some APIs bury rate limit data in response bodies. Truto normalizes all of these into consistent response headers:

• ratelimit-limit: The maximum number of requests permitted in the current window.
• ratelimit-remaining: The number of requests remaining before you hit the limit.
• ratelimit-reset: The number of seconds until the rate limit window resets.

This normalization is based on the IETF RateLimit header fields draft, which defines a set of standard HTTP header fields to enable rate limiting, including RateLimit-Policy for quota policies and RateLimit for the currently remaining quota.

Here is what reading those headers looks like in practice:

const response = await fetch('https://api.truto.one/unified/employees', {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'X-Integrated-Account-ID': 'acct_abc123'
  }
});
 
const remaining = parseInt(response.headers.get('ratelimit-remaining'));
const resetInSeconds = parseInt(response.headers.get('ratelimit-reset'));
 
if (response.status === 429 || remaining === 0) {
  // You decide the backoff strategy
  await sleep(resetInSeconds * 1000);
  // Retry with your own logic inside your HIPAA-compliant environment
}

By passing these standardized headers back to your application, Truto empowers your engineering team to implement precise, deterministic backoff logic on your own infrastructure. You retain complete control over the data lifecycle. If a request needs to be queued, it gets queued in your secure, HIPAA-compliant environment, governed by your own internal policies, rather than leaking into an opaque third-party middleware queue.

For a deeper dive into architecting resilient systems around these headers, review our guide on best practices for handling API rate limits.

The Proxy API: An Escape Hatch for Custom Endpoints

Another reality of enterprise integrations is that unified data models never cover 100% of a provider's API surface. You will inevitably encounter a customer who needs access to a highly specific, undocumented endpoint or a custom object unique to their NetSuite, Workday, or Epic deployment.

Sync-and-cache platforms struggle with this. If the data does not fit their rigid schema, their database cannot store it, and you cannot query it. You are forced to build a parallel, custom integration alongside the unified API.

Truto solves this through its Proxy API. Because the architecture is entirely pass-through, the platform provides direct, unmapped access to integration resources. The proxy layer handles the OAuth token refresh lifecycle proactively before expiry, injects the correct authentication headers, and routes your request directly to the provider. What you send is what the third-party API receives, and what it returns is what you get back.

This zero-code execution pipeline ensures that you can hit any endpoint, at any time, without waiting for a vendor to update their unified schema. It is a critical requirement for teams building deep, enterprise-grade integrations where flexibility is just as important as compliance.

Real-Time vs. Background Sync: Quick Legend

If you are looking for an integration platform with unified API support for your enterprise SaaS product, the single most important architectural question is: does the platform fetch data at request time, or sync it in the background?

These two models have fundamentally different compliance, freshness, and reliability profiles. Here is the distinction:

• Request-time (pass-through): Your app makes an API call, the integration platform forwards it to the upstream provider in real time, transforms the response in memory, and returns it. No data is stored. Every response is live.
• Sync-and-cache (background sync): The integration platform polls upstream APIs on a schedule (ranging from every few minutes to every 24 hours), stores normalized copies in its own database, and serves your queries from that cache.

Neither model is universally better. But in regulated industries like healthcare, the storage question is the compliance question. Data at rest on a third party triggers BAA obligations, sub-processor disclosures, and breach liability chains that pass-through architectures avoid entirely.

Platform Comparison: Request-Time vs. Sync-and-Cache

When evaluating a unified API integration platform, knowing the underlying data architecture is non-negotiable. The table below classifies the major platforms based on their publicly documented behavior as of early 2026.

A few things stand out. Merge's core architecture relies on background data synchronization, and Merge stores customer records as part of its sync architecture. Sync frequency is the rate at which Merge initiates requests to fetch data from third-parties, and on the free or launch plan, that frequency defaults to daily. Apideck does not store your data; API calls are processed in real-time and passed directly from the source to your app. Kombo mirrors data in the source systems into a database at regular intervals. StackOne proxies every request in real-time, and no customer data is persisted by default. Nango stores cached records and synced data in Postgres when using its sync engine, though its proxy mode operates without storage.

For teams selling into healthcare, the "Stores Customer Data" column is the first filter. If the answer is "yes," you are adding a sub-processor that holds ePHI - and the BAA, breach notification, and audit requirements follow.

Implications for Enterprise Workflows

The architecture your integration platform uses directly shapes what you can and cannot do in production enterprise workflows. Here are three scenarios where the difference is concrete:

1. Real-time employee offboarding

When an employee is terminated, downstream systems - identity providers, device management tools, benefits platforms - need to reflect that change immediately. With a request-time architecture, your app writes the termination to the HRIS through the unified API, and the change propagates instantly. With a sync-and-cache platform, the termination is recorded in the source system, but your integration layer won't reflect it until the next sync cycle completes. That gap - minutes to hours - is a security exposure window where the terminated employee may still have active access.

2. Prior authorization checks against EHR data

A digital health product checking insurance eligibility or prior authorization status needs current data. If your integration platform is serving a cached snapshot that is three hours old, you risk acting on stale coverage information. Pass-through architectures return whatever the EHR system has right now, which is the only acceptable source of truth for clinical workflows.

3. Aggregate analytics and reporting

This is where sync-and-cache architectures genuinely shine. If you need to run cross-tenant analytics, generate compliance reports across hundreds of HRIS connections, or build dashboards that query historical data, a cached database gives you SQL-like flexibility that no pass-through API can match. You cannot run a GROUP BY across a live upstream API.

The practical answer for most healthcare SaaS teams is to recognize which workflows are latency-sensitive and compliance-critical (use pass-through) versus which are analytical and tolerant of eventual consistency (use sync or build your own data warehouse). Picking a unified API integration platform that supports both patterns - real-time proxy for sensitive operations and a raw proxy for direct API access - gives you the most flexibility without doubling your vendor count.

SIG / CAIQ Procurement FAQ: Paste-Ready Answers

Enterprise healthcare buyers run every SaaS vendor through some combination of the Standardized Information Gathering (SIG) questionnaire, the Cloud Security Alliance's CAIQ, and a bespoke HIPAA addendum. The questions below are the ones that most commonly stall deals when a sync-and-cache integration vendor sits inside your stack. Use these as starting-point answers when your architecture is genuinely pass-through, then edit to match your exact vendor list and controls.

Q: Does any third-party sub-processor store, cache, or replicate our data?

A: Our integration middleware uses a real-time pass-through architecture. Customer API payloads (including ePHI) are processed in transit, transformed in memory, and returned to our application without being written to durable storage on the middleware vendor's infrastructure. The vendor retains only (a) connection metadata such as OAuth tokens in an encrypted vault, and (b) operational metadata such as HTTP status codes, latency, and timestamps. No request bodies or response bodies containing customer data are persisted by the middleware.

Q: Where is ePHI stored, and who has access?

A: ePHI is stored in two places: (1) the upstream source system (e.g., Epic, athenahealth, Workday), which serves as the system of record, and (2) our own HIPAA-compliant environment as required for the operation of our product. The integration middleware is not a storage location for ePHI. Access to our own copy of ePHI is governed by role-based access controls, MFA, and reviewed quarterly.

Q: Is a Business Associate Agreement (BAA) executed with every sub-processor that touches ePHI?

A: Yes. A BAA is executed with the integration middleware vendor prior to any production traffic. Although the pass-through architecture significantly reduces the vendor's exposure to ePHI, we treat the integration layer as a Business Associate to preserve a conservative HIPAA posture and align with HHS guidance on cloud service providers.

Q: How are OAuth credentials, API keys, and secrets protected?

A: Connection credentials are stored in an encrypted vault by the integration vendor. Tokens are refreshed proactively before expiry so that failing requests do not trigger retry queues that could hold ePHI. Credentials are never returned to the client application, logged in plaintext, or exposed in observability tools.

Q: How does the platform handle HTTP 429 rate limits and 5xx errors? Where are payloads stored during retry backoff?

A: Rate-limit errors are passed directly back to our application through standardized IETF ratelimit-limit, ratelimit-remaining, and ratelimit-reset response headers. The integration vendor does not maintain a retry queue. All backoff and retry logic executes inside our HIPAA-compliant environment, using our own controls for durable state and encryption at rest.

Q: What request or response data is logged for observability?

A: Metadata only: HTTP method, endpoint path, status code, latency, integration identifier, and timestamps. Request bodies and response bodies are not logged by the middleware. This is verified through the vendor's SOC 2 report and their documented logging policy.

Q: How is data encrypted in transit and at rest?

A: All API traffic uses TLS 1.2 or higher. Connection credentials stored at rest in the vendor's vault are encrypted using AES-256 or equivalent. Because customer payloads are not persisted on vendor infrastructure, there is no additional ePHI at rest on the middleware to encrypt.

Q: What is the breach notification timeline?

A: The executed BAA requires the middleware vendor to notify us of any confirmed breach or reasonably suspected breach of PHI within a defined window (typical language: no later than 48 hours after discovery), with full 45 CFR 164.410 reporting within the statutory deadlines. Our own downstream breach notification obligations to customers and to OCR run from the moment we receive that notification.

Q: How is data deleted when a customer disconnects an integration or terminates the contract?

A: Because customer payloads are not stored, disconnection at the middleware layer is limited to revoking OAuth tokens from the encrypted vault and deleting connection metadata according to the vendor's documented retention schedule. Data held inside our own environment follows our contractually agreed data return or destruction procedure.

Q: Which sub-processors does the middleware use, and where do they process data?

A: A current sub-processor list is maintained by the vendor and referenced in the BAA. In a pass-through architecture, sub-processors provide transient compute and networking; they do not persist ePHI. New or replacement sub-processors that would touch ePHI trigger a 30-day advance notice with a right to object.

Q: Can we restrict data processing to a specific geographic region?

A: Confirm with your vendor. Some pass-through platforms support region-pinned request processing so that traffic from EU or US-only customers stays within the required jurisdiction. Because no ePHI is stored at rest on the middleware, data residency for pass-through traffic reduces to the region of the compute nodes handling the request.

Q: How does the platform support our right-to-audit obligations?

A: The BAA grants us the right to review the vendor's SOC 2 Type II report annually, review penetration test summaries, and receive reasonable cooperation in the event of an OCR investigation. Because payloads are not stored on the vendor, on-site data audits are typically unnecessary; the audit scope is limited to metadata and infrastructure controls.

Sample BAA Clauses and Contract Checklist

Before signing a BAA with any integration vendor, verify the following clauses are present and clearly aligned with the vendor's actual architecture. The sample language below is provided as a drafting starting point only. Have healthcare counsel review before use; every deal has jurisdiction-specific nuance.

Contract checklist

• Defines "Protected Health Information" and "ePHI" consistent with 45 CFR 160.103
• Names all sub-processors that may touch ePHI, with 30-day advance notice for new additions
• Limits permitted uses and disclosures (no secondary use for model training, product analytics, benchmarking, or de-identified data products on customer data)
• Specifies breach notification timeline (target 48 hours or less from discovery)
• Requires data return or destruction on termination
• Grants audit rights and requires cooperation with OCR investigations
• Provides indemnification for vendor-caused breaches
• Includes an explicit representation of what is and is not stored at rest
• Requires the vendor to maintain a SOC 2 Type II report (or equivalent) covering the services
• Requires notification within a defined window if the vendor's architecture materially changes (e.g., introduces caching)
• Addresses HITECH Act obligations, including 45 CFR 164.410 reporting

Sample clause: No secondary use of ePHI

Business Associate shall not use or disclose Protected Health Information for any purpose other than as expressly permitted or required by this Agreement, the Underlying Services Agreement, or by law. Without limiting the foregoing, Business Associate shall not use PHI, whether or not de-identified, to train, evaluate, or fine-tune machine learning or artificial intelligence models, to generate benchmarks or industry reports, or to develop derivative data products, unless Covered Entity has expressly authorized such use in a separate written instrument.

Sample clause: Pass-through architecture representation

Business Associate represents and warrants that the Services are operated as a real-time pass-through processor. Protected Health Information transmitted through the Services is processed in transit and is not persisted to durable storage on Business Associate's infrastructure. Business Associate may log operational metadata (including HTTP status codes, latency measurements, endpoint identifiers, and connection identifiers) for the operation and support of the Services, provided that such metadata does not include the contents of request or response bodies containing PHI. Any material change to this architecture that would result in the persistence of PHI on Business Associate's infrastructure shall be communicated to Covered Entity in writing at least thirty (30) days prior to taking effect, and Covered Entity shall have the right to terminate this Agreement without penalty upon such change.

Sample clause: Retry and queue handling

Business Associate shall not maintain a durable retry queue, buffer, or dead-letter store containing PHI in response to upstream rate limits, transient errors, or other failure modes. Rate-limit and error responses from upstream systems shall be surfaced to Covered Entity's application through documented response headers or status codes, allowing Covered Entity to implement retry logic within its own environment.

Sample clause: Breach notification

Business Associate shall notify Covered Entity of any Breach of Unsecured Protected Health Information without unreasonable delay, and in no event later than forty-eight (48) hours following Discovery. Such notification shall identify each individual whose PHI has been, or is reasonably believed to have been, accessed, acquired, used, or disclosed during the Breach, together with the information required under 45 CFR 164.410 and any additional information Covered Entity may reasonably request to fulfill its own notification obligations.

Sample clause: Sub-processor management

Business Associate shall maintain and make available to Covered Entity a current list of Subcontractors that create, receive, maintain, or transmit PHI on Business Associate's behalf. Business Associate shall provide Covered Entity with thirty (30) days' prior written notice of any addition or replacement of such Subcontractors. If Covered Entity reasonably objects to a proposed Subcontractor on data protection grounds, Covered Entity shall have the right to terminate this Agreement without penalty.

Sample clause: Return or destruction on termination

Upon termination of this Agreement, Business Associate shall return or destroy all PHI received from, or created or received by Business Associate on behalf of, Covered Entity, and shall retain no copies. Because Business Associate does not persist PHI to durable storage in the ordinary course of providing the Services, this obligation shall be satisfied by (a) revocation of all authentication credentials associated with Covered Entity, (b) deletion of connection metadata in accordance with the vendor's documented retention schedule, and (c) written attestation of the foregoing within thirty (30) days of termination.

Sample clause: Right to audit

Business Associate shall, upon reasonable notice and no more than once per calendar year (except in the event of a Breach or a regulatory investigation), make available to Covered Entity or its designated auditor its most recent SOC 2 Type II report, penetration test summary, and HIPAA Security Rule risk analysis. Business Associate shall cooperate in good faith with any investigation conducted by the Office for Civil Rights or another regulator with jurisdiction over Covered Entity or the PHI processed under this Agreement.

Decision Matrix: Pass-Through vs Sync-and-Cache by Use Case

Not every integration workflow needs the same architecture. The right question is not "which platform is best" but "which pattern is right for this specific workflow." Use the matrix below to map concrete use cases to the appropriate architecture. When a workflow appears in the sync-and-cache column, the recommendation is to cache in your own HIPAA-compliant data warehouse - not in a third-party integration vendor's database.

Rule of thumb: if the workflow touches ePHI and needs current data, use a pass-through pattern. If the workflow needs aggregation, historical depth, or search across many records, cache the data inside a HIPAA-compliant environment that you control. That split lets you answer "no" to the sub-processor storage question on procurement questionnaires while still supporting analytics and reporting requirements internally.

Evaluating API Middleware for Enterprise Compliance

When evaluating integration tools for healthcare or enterprise SaaS, product managers and engineering leaders must look past the marketing copy. "Secure" and "compliant" are meaningless adjectives unless backed by architectural realities. To determine which unified API does not store customer data, use this technical checklist to evaluate any integration tool for enterprise compliance:

Architecture Verification

1. Verify Zero Data Retention: Ask explicitly, "Do you store our API request or response payloads on disk, even temporarily in a queue?" Ask for architectural documentation regarding webhook payloads, request/response logging, and sync job outputs. If the answer involves a database, you have a compliance liability.
2. Where Does Data Transformation Happen?: In-memory transformations (using expression languages like JSONata) leave no persistent trace. ETL pipelines that write to intermediate storage do.
3. Check BAA Willingness: Will the vendor sign a Business Associate Agreement? Even with a pass-through architecture, the safest approach is to have a BAA in place. If they use a sync-and-cache model and refuse a BAA, you cannot legally use them for healthcare data.

Encryption and Transport Security

4. TLS 1.2+ for All Data in Transit: This is table stakes, not a differentiator, but still requires verification.
5. No Payload Logging in Production: Verify that the vendor's observability stack logs metadata (status codes, latency, resource types) without capturing request or response bodies containing ePHI.
6. Proactive Authentication Management: The platform should refresh OAuth tokens proactively before expiry to avoid failed requests that might trigger retry queues.

Transparency in Error Handling

7. Audit the Retry Mechanism: Ask how they handle HTTP 429 errors. If they claim to automatically retry failed requests, ask where the payload is stored between retries. Automatic retries require durable state. Rate limit errors should be visible to you, not absorbed.
8. Contextual Upstream Errors: Upstream errors should pass through with context. A generic "500 Internal Server Error" from your integration layer masks the actual problem and makes debugging healthcare data pipelines much harder.

Sub-Processor and Data Residency

9. Sub-Processor Chain: How many sub-processors touch ePHI? Fewer is better. A pass-through architecture that doesn't store data inherently limits the sub-processor chain.
10. Data Processing Region: For healthcare organizations with data residency requirements, the ability to control where API requests are processed (not just stored) matters immensely.

The Penalty Math That Should Drive Your Architecture Decision

HIPAA violation penalties in 2026 include civil monetary penalties ranging from $145 to $2,190,294 per violation, depending on the level of culpability. That is per violation, not per incident. A single breach affecting thousands of patient records can trigger penalties for each individual's data that was improperly handled.

OCR enforcement actions have been increasing, ending 2025 with 21 settlements and civil monetary penalties. The trend is clear: HHS is not slowing down its scrutiny of digital health platforms and their vendors.

Consider the math from the integration vendor's perspective. If your sync-and-cache middleware stores normalized copies of ePHI across hundreds of your customers' connected accounts, a single breach on their infrastructure exposes data from every one of those connections. Your exposure is not isolated to your own security posture—it is chained to theirs.

A pass-through architecture doesn't eliminate HIPAA risk. Nothing does. But it removes one of the most dangerous variables from the equation: a third-party database full of your customers' healthcare data that you don't control, can't audit, and may not even know exists until the breach notification arrives.

Choosing the Right Architecture for Your Healthcare SaaS

The decision between pass-through and sync-and-cache isn't purely ideological. It is driven by your specific use case.

Choose pass-through when:

• You sell to healthcare, finance, or government clients with strict data handling requirements.
• Your integration needs are primarily real-time reads and writes (CRUD operations).
• Your customers' InfoSec teams have flagged sub-processor data storage as a deal blocker.
• You are building HIPAA-compliant integrations for healthcare SaaS.

Consider sync-and-cache when:

• You need offline analytics or aggregate queries across connected accounts.
• Your use case requires historical data that upstream APIs do not retain.
• You are operating in a non-regulated domain where compliance isn't a strict gate.

For many healthcare SaaS teams, the practical answer is a hybrid: use a pass-through API for real-time CRUD operations on sensitive data, and sync only the non-sensitive metadata you actually need for analytics. Truto supports both patterns—the unified API for pass-through operations and a Proxy API for direct, unmapped access when unified models don't cover specific EHR or HRIS endpoints.

Strategic Wrap-Up

The architecture you choose for your integration layer fundamentally dictates your go-to-market velocity in the enterprise segment.

Sync-and-cache unified APIs optimize for developer convenience at the expense of security. They force you to trust a third-party database with your most sensitive customer data, triggering brutal InfoSec reviews and expanding your compliance footprint.

Real-time pass-through architectures optimize for trust. By processing data entirely in transit, normalizing schemas in memory, and passing rate limit controls back to the caller, you eliminate shadow data. You keep your compliance boundaries tight. You give your sales team an integration story that enterprise security teams actually want to hear.

Building integrations is hard enough. Do not let your middleware vendor become the reason you lose your next major deal. Pick the architecture that lets you answer Question #47 with confidence.