Which Unified API Does Not Store Customer Data in 2026?

If your enterprise deal just got stuck because InfoSec flagged your integration middleware for caching customer data, you are reading the right article. The short answer: Truto, Apideck, Unified.to, and Knit all operate pass-through architectures that do not persist customer payload data at rest. Merge.dev, the largest player in the space, uses a sync-and-cache model by default — though it now offers a premium add-on for streaming-only delivery.

This distinction matters more than most product managers realize. For senior PMs and engineering leaders at B2B SaaS companies, the architecture your unified API vendor uses determines whether it shows up as a data sub-processor on your compliance documentation — and whether your 6-month enterprise deal closes or dies in security review.

This guide breaks down the architectural realities of unified APIs, compares sync-and-cache versus pass-through models, and details exactly how zero-storage normalization works under the hood.

The Hidden Compliance Cost of Unified APIs

Every B2B SaaS company selling upmarket hits the same wall. The prospect's security team sends a 200-question vendor questionnaire, and somewhere around question #47, they ask: "Does any third-party sub-processor store, cache, or replicate our data?" If you need an integration tool that doesn't store customer data to get past procurement, this question is the ultimate tripwire.

The pressure to ship integrations is constant. Your sales team is losing deals because your application lacks a native Workday or Salesforce connector. Engineering is bottlenecked maintaining existing integrations, fighting undocumented edge cases, and dealing with terrible vendor API documentation. A unified API — one interface that normalizes data across dozens of platforms — looks like the obvious shortcut.

But speed comes with a hidden security cost if you choose the wrong architecture.

Many unified API platforms rely on a "sync-and-cache" model. To normalize the data, they continuously poll the third-party provider, extract your customers' records, and store them in their own multi-tenant databases. Every unified API vendor you add to your stack becomes a sub-processor with access to your customers' most sensitive data. Whether it is employee PII from HRIS systems, revenue figures from accounting platforms, or customer contact lists from CRMs — the moment that data touches a third-party server at rest, your compliance surface area expands.

Enterprise InfoSec teams are deeply skeptical of this setup, and the financial exposure behind their scrutiny is real. The average cost of a data breach in 2025 reached $4.44 million globally, while in the United States, the average hit a record $10.22 million — up 9% year-over-year. If you are selling into healthcare, where HRIS and benefits data flows through your integrations, the numbers are worse: healthcare was the most expensive industry for breaches for the 14th consecutive year, with average costs of $7.42 million and a containment timeline of 279 days.

When a third-party integration vendor stores your customers' data, they become a sub-processor under GDPR. A sub-processor is any third-party company that processes personal data on behalf of your organization. The relationship creates a chain of responsibility: your client (the data controller) trusts you to handle their data properly, and when you pass some of that processing to a sub-processor, you remain responsible for ensuring compliance throughout the entire chain. Your prospect's legal team now has to evaluate not just your security posture, but your integration vendor's security posture too.

This is not an abstract risk. Research shows that 30% of breaches involved data spread across multiple environments, with the highest average cost at $5.05 million and the longest average lifecycle at 276 days. Every additional environment that holds customer data is another attack surface. When an enterprise buyer sees that their data will be synced to a middleware provider's database, they will demand to audit that provider's data residency, encryption standards, retention policies, and breach notification timelines. Deals stall. Sometimes they die entirely.

Sync-and-Cache vs. Pass-Through Architecture

Unified APIs normalize data from dozens of third-party platforms (Salesforce, HubSpot, BambooHR, Workday) into a common schema. The fundamental architectural question is where that normalization happens — and whether it requires storing your customers' data to do it.

graph LR
    subgraph "Sync-and-Cache"
        A1[Your App] -->|API Call| B1[Unified API<br>Vendor]
        B1 -->|Periodic Sync| C1[Third-Party<br>API]
        B1 --- D1[(Vendor's<br>Database)]
    end
    subgraph "Pass-Through"
        A2[Your App] -->|API Call| B2[Unified API<br>Vendor]
        B2 -->|Real-Time Proxy| C2[Third-Party<br>API]
    end
    style D1 fill:#ff6b6b,stroke:#333,color:#fff

Sync-and-cache architecture

The vendor periodically polls the third-party API, extracts customer records, normalizes them, and stores the result in its own database. When you call the unified API, you are reading from the vendor's cache — not from the source system.

Pros: Faster response times. Handles rate limits gracefully since reads do not hit the third-party API. Can offer SQL-like querying across integrations.

Cons: Your customers' sensitive data (employee PII, financial records, CRM contacts) now lives on a third-party server. The vendor becomes a sub-processor. You inherit their breach risk. Data goes stale between sync intervals. Retention policies become your problem.

Pass-through architecture

The vendor proxies your API request directly to the third-party in real time, normalizes the response on the fly, and returns it to your application. No customer payload data is stored at rest on the vendor's infrastructure.

1. Your application requests /unified/crm/contacts.
2. The unified API engine translates your unified query parameters into the syntax required by the target system.
3. The engine makes a live HTTP call directly to the third-party provider.
4. The third-party provider returns the raw response.
5. The engine translates the raw response into the unified schema in-memory and returns it to your application immediately.

Pros: No data residency issues. The vendor is not a data sub-processor for payload data. Always-fresh data from the source. Simpler compliance story.

Cons: Response times depend on the third-party API's latency. You are subject to the source system's rate limits. No offline querying — if the third-party is down, you get nothing.

Both architectures have legitimate use cases. If you need to run analytics over historical employee data across 50 HRIS systems, a sync-and-cache model is genuinely useful. But if your primary goal is to read and write records through integrations while keeping your compliance surface area minimal, pass-through is the architecture that will not block your enterprise deals.

For a deeper analysis of these trade-offs, see our comparison of real-time and cached unified APIs.

Which Unified APIs Do Not Store Customer Data?

Here is an honest breakdown of the major unified API vendors and their data storage posture as of early 2026, based on each vendor's public documentation and security pages.

Truto

Truto operates a 100% pass-through architecture. When you call GET /unified/crm/contacts, Truto proxies the request to the underlying CRM (Salesforce, HubSpot, etc.), transforms the response into the unified schema using declarative expressions evaluated in-transit, and returns the normalized result. No customer records are written to a database at any point.

The platform was engineered from the ground up to operate without integration-specific code or shadow databases. Schema normalization is handled entirely in-transit using declarative JSONata expressions. This means no customer payload data — CRM contacts, HRIS records, ATS candidates — is ever stored at rest, providing built-in SOC 2 and HIPAA readiness by entirely removing the unified API provider from the data custody chain.

Truto stores credentials (encrypted OAuth tokens and API keys), integration configuration, and connection metadata. It does not store customer payload data. For organizations that need even stronger isolation, Truto offers on-premise deployment and single-tenant cloud options with configurable data processing regions - see the next section for details. For a deeper dive, see our post on why zero-storage matters for compliance-strict SaaS.

Apideck

Apideck does not store customer data. API calls are processed in real-time and passed directly from the source to your application. Their architecture is conceptually similar to Truto's pass-through model, and their SOC 2 Type 2 compliance combined with no-data-storage has made them a strong candidate for security-conscious teams.

Unified.to

Unified.to also operates a pass-through model. They do not store end-user data or credentials. Requests proxy through to the source system in real time, and you stay in control of where data flows and how it is handled.

Knit

Knit differentiates itself from legacy providers with a security-first architecture. They operate a zero-storage model where customer data never touches their servers at rest, focusing heavily on the compliance benefits of not maintaining a secondary database of customer records.

The Contrast: Merge.dev

Merge is transparent about its approach: they deliberately chose to store data rather than operating as a pass-through-only platform. Storing data allows Merge to increment on its database rather than performing a full refresh on each sync, letting them resync data more frequently while respecting third-party rate limits. Customer data and credentials are stored indefinitely until actively deleted by the Merge customer.

Merge now offers a premium feature called Destinations that streams data directly to your infrastructure without storing it on Merge's servers. This is a step in the right direction, but it is an add-on to an annual plan — not the default architecture. If you use Merge's standard configuration, your customers' HRIS records, CRM contacts, and financial data persist on Merge's infrastructure until you explicitly delete them.

On-Premise Unified APIs: When Pass-Through Cloud Is Not Enough

For some organizations, even a zero-storage pass-through architecture running in a vendor's cloud is not sufficient. Government contractors, defense subcontractors, certain healthcare systems, and financial institutions operating under strict data residency mandates need every component of the integration pipeline - including the normalization engine itself - running inside their own network perimeter.

This is where on-premise (self-hosted) unified API deployments come in.

Which vendors offer on-premise deployment?

Among purpose-built unified API platforms, on-premise options are rare. Most vendors are cloud-only SaaS.

Truto offers on-premise deployment as part of its enterprise plan, alongside single-tenant cloud and configurable data processing regions. The same declarative, config-driven engine that runs in Truto's cloud can be deployed inside your infrastructure. Because Truto's architecture is entirely data-driven - all integration behavior is defined by JSON configuration and JSONata expressions, with zero integration-specific code - the self-hosted deployment runs the identical codebase, not a stripped-down "enterprise edition."

Apideck, Unified.to, and Knit are cloud-only platforms as of early 2026. Their pass-through architectures minimize data exposure, but the normalization engine and credential storage still run on vendor-managed infrastructure.

For broader integration needs (iPaaS rather than unified API), platforms like MuleSoft Anypoint and WSO2 support hybrid and on-premise deployment. But these are general-purpose API management platforms - not purpose-built unified APIs with common data models across SaaS categories like CRM, HRIS, and ATS.

On-premise vs. pass-through cloud: how they compare

When to choose on-premise over pass-through cloud

On-premise deployment makes sense when your compliance requirements go beyond what even a zero-storage cloud pass-through can satisfy:

• Regulatory mandates prohibit data from transiting third-party infrastructure. Some government and defense contracts (FedRAMP High, ITAR) prohibit any customer data from passing through third-party cloud infrastructure, even transiently in-memory.
• You need full control over credential storage. If your security policy requires all OAuth tokens and API keys to reside in your own HSM or vault infrastructure, self-hosted is the only option.
• Air-gapped or restricted network environments. Organizations operating without public internet access need on-premise deployments that can reach internal or on-premise SaaS instances directly.
• Your customers' procurement process explicitly requires it. Some enterprise buyers will not approve any vendor whose infrastructure touches their data, regardless of whether that vendor stores it.

For everyone else - including most enterprise B2B SaaS companies selling into regulated industries - a pass-through cloud architecture is usually sufficient. The practical question is whether your buyer's InfoSec team cares about storage (pass-through cloud solves this) or transit (on-premise solves this).

How Truto Normalizes Data Without a Database

The obvious question is: if you do not store data, how do you normalize it? Different CRMs call the same field different things — Salesforce uses FirstName, HubSpot nests it under properties.firstname. Someone has to translate.

Most sync-and-cache platforms solve this by extracting data into their own database, running transformations offline, and serving the normalized result from cache. Behind their unified facade, they maintain separate code paths for each integration with integration-specific database columns, dedicated handler functions, and hardcoded business logic.

Truto takes a fundamentally different approach. The entire platform contains zero integration-specific code. Integration behavior is defined entirely as data: JSON configuration and declarative JSONata expressions. The runtime engine is a generic pipeline that reads this configuration and executes it in-transit.

The zero-storage pipeline

When a unified API request comes in — for example, GET /unified/crm/contacts?integrated_account_id=abc123 — the following pipeline executes:

Step 1: Resolve Configuration. The engine loads the integration configuration (a JSON blob describing the API's base URL, auth scheme, and pagination strategy) and the integration mapping (JSONata expressions for translating formats). No customer payload data is loaded at this step.

Step 2: Transform the Request In-Transit. The unified request is translated into the third-party's native format. If you pass a unified query parameter, the engine evaluates a JSONata expression to map it. HubSpot requires constructing a complex filterGroups array for searches; Salesforce requires building a SOQL WHERE clause. The engine does not know which one it is doing — it simply evaluates the JSONata expression provided in the configuration and attaches the result to the outbound HTTP request.

Step 3: Execute the Live HTTP Call. The proxy layer makes the HTTP call directly to the third-party provider using the constructed URL and injected authentication tokens. It handles pagination (cursor, offset, link-header) dynamically based on the configuration.

Step 4: Transform the Response In-Transit. When the raw response returns, the engine evaluates a JSONata response mapping expression against each item. For Salesforce, this might map flat PascalCase fields into the unified schema. For HubSpot, it might extract data from nested properties objects. The data is reshaped in memory and immediately returned to the client. The original response is also preserved as a remote_data field so you can always access the raw data your provider returned.

/* Example: In-transit JSONata mapping for Salesforce Contacts */
response.{
  "id": Id,
  "first_name": FirstName,
  "last_name": LastName,
  "name": $join($removeEmptyItems([FirstName, LastName]), " "),
  "email_addresses": [{ "email": Email }],
  "created_at": CreatedDate,
  "updated_at": LastModifiedDate
}

A three-level override system (without storing customer data)

One criticism of pass-through architectures is that they cannot handle customization — different customers need different field mappings for the same integration. Truto solves this with a three-level override hierarchy:

• Platform-level defaults — the base mapping that works for most customers.
• Environment-level overrides — a customer's environment can modify any mapping without affecting others.
• Account-level overrides — individual connected accounts can have their own mapping adjustments.

These overrides are configuration data, not customer payload data. They describe how to transform data, not the data itself. When a customer's Salesforce instance has custom fields that need special handling, only the mapping rules change — no customer records are stored or cached. The mapping configuration is lightweight JSON containing field names, transformation rules, and endpoint paths. It contains zero customer PII.

The honest trade-offs

Pass-through is not magic. Because Truto does not cache data, every API call hits the third-party system in real time. That means:

• Latency depends on the source system. If Salesforce's API takes 800ms to respond, your unified API call takes at least 800ms plus transformation overhead.
• Rate limits are partially your problem. Truto handles rate limit detection and surfaces standardized retry headers, but if your customer's BambooHR instance is rate-limited, you cannot work around it by reading from a cache.
• No offline querying by default. You cannot run SQL against data that is not stored. Truto does offer an optional sync feature called RapidBridge that syncs data directly to your data store if you need this — keeping the data in your infrastructure, not Truto's.

These are real trade-offs you should evaluate based on your use case. For the majority of B2B SaaS applications — reading and writing records through integrations, powering customer-facing features, syncing data on demand — the latency difference is negligible and the compliance benefit is massive.

Questions to Ask Your Unified API Vendor During Security Reviews

When your InfoSec team evaluates a unified API vendor, do not accept marketing claims at face value. Terms like "real-time" or "secure" do not guarantee a pass-through architecture. Here is a concrete checklist, organized by category.

Data storage and residency

• "Do you persist any customer payload data at rest?" Not connection metadata or OAuth tokens — actual customer records (employee PII, CRM contacts, financial data). Acceptable answer: No, all payload data is processed in memory and immediately discarded after the HTTP response is sent. Red flag: "We store it temporarily for caching" or "we sync it to provide cross-platform search."

• "What is your data retention policy for customer payloads?" If the answer is not "we don't store them," ask how long data persists and what triggers deletion. Also ask about API logs — a vendor that logs full request and response bodies for 30 days is storing your customers' data by another name.

• "Will we need to list you as a data sub-processor?" This is the litmus test. Under GDPR, a processor cannot engage another processor without prior written authorization from the controller. If the vendor stores customer data, they must appear as a sub-processor. If they do not store payload data, they act strictly as a conduit.

Architecture verification

• "Can you provide an architecture diagram showing the data flow for a unified API call?" You want to see whether data passes through a database or is processed in-memory.

• "How do you handle custom fields and custom objects?" Acceptable: mapped dynamically in-transit using transformation expressions, or passed through in a raw data object. Red flag: dynamically generated columns in the vendor's database to accommodate custom fields.

• "What happens when the third-party API is down?" Pass-through vendors will return an error. Cache vendors may serve stale data. Know which behavior you are getting.

Deployment model and data residency

• "Do you offer on-premise or self-hosted deployment?" If your security requirements prohibit customer data from transiting any third-party infrastructure - even in-memory - you need a vendor that can deploy inside your network. Ask whether the self-hosted version is the same codebase or a separate, limited product.

• "Can we run your platform in our own cloud VPC or air-gapped environment?" For organizations with strict network segmentation, this determines whether the vendor is even viable. Ask about container-based deployment, dependency requirements, and whether the platform needs to phone home for licensing.

• "What data processing regions do you support?" If on-premise is overkill but you have data residency requirements (EU-only processing, for example), confirm the vendor can run in your required region. Ask whether this is a dedicated instance or a shared multi-tenant cluster in that region.

• "Is single-tenant cloud deployment available?" A middle ground between shared multi-tenant cloud and full on-premise. Single-tenant gives you a dedicated instance managed by the vendor, without sharing infrastructure with other customers.

Compliance documentation

• "Can I see your SOC 2 Type II report?" Not the marketing badge — the actual report. Review the system description for mentions of customer data storage.

• "Do you have a published sub-processor list?" Any vendor that stores customer data should maintain one. Review it to understand the full chain of custody.

• "Do you support HIPAA BAAs?" If you are in healthcare SaaS, this is non-negotiable. A vendor that does not store PHI has a much simpler HIPAA story than one that does.

For a deeper dive into passing enterprise security reviews with third-party integration tools, see our practical guide for engineering and product leaders.

Making the Right Call for Your Stack

The unified API market is splitting into two clear camps: vendors that store your customers' data and vendors that do not. Neither approach is universally wrong — the right choice depends on your product's requirements, your customers' security expectations, and your risk tolerance.

If you are selling into enterprises with strict data governance policies — financial services, healthcare, government contractors, or any company with a serious InfoSec team — a pass-through architecture removes an entire category of compliance questions from your vendor security reviews. You do not need to explain where your customers' HRIS data lives on a third-party server, because it doesn't.

If your compliance requirements go further - data cannot transit any third-party infrastructure, credentials must live in your own vault, or you operate in an air-gapped environment - look for a vendor that offers on-premise deployment without sacrificing the unified API's core value: one interface across dozens of integrations.

If you need to run analytics over historical integrated data, a caching architecture (or a hybrid like Merge Destinations) may be the better fit — just go in with eyes open about the sub-processor implications.

By adopting a zero-storage, pass-through unified API, you get the velocity of shipping dozens of integrations in weeks instead of years without sacrificing the security posture required to close enterprise deals. You eliminate the sub-processor conversation entirely, and your sales team stops having to defend a third-party's database architecture to antagonistic InfoSec auditors.