Why Truto is the Best Zero-Storage Unified API for Compliance-Strict SaaS

If you're building B2B SaaS and your enterprise prospects keep flagging third-party data storage in security reviews, this post is for you. We'll break down why the traditional "sync-and-cache" integration architecture is a compliance liability, what a zero-storage unified API actually looks like under the hood, and how Truto's pass-through architecture fits — including its honest trade-offs.

Traditional integration tools cache your customers' sensitive data on their servers, expanding your compliance footprint with every new connection. A zero-storage architecture processes data entirely in transit — no persistent copies, no shadow databases, no surprise sub-processor conversations during your SOC 2 audit.

The $10 Million Problem: Why Enterprise InfoSec Is Blocking Your Deals

Every B2B SaaS company selling upmarket eventually hits the same wall: the prospect's InfoSec team sends over a 200-question vendor security questionnaire, and question #47 asks, "Does any third-party sub-processor store, cache, or replicate our data?"

If your integration layer caches customer HR records, CRM contacts, or financial data on a middleware provider's servers, the answer is yes. And that answer triggers a cascade of follow-up questions about data residency, encryption standards, retention policies, breach notification timelines, and sub-processor agreements. Deals stall for weeks. Sometimes they die.

The financial stakes behind this scrutiny are real. The average cost of a data breach for U.S. companies jumped 9% to an all-time high of $10.22 million in 2025, as the global average cost fell 9% to $4.44 million, IBM said in its 20th annual Cost of a Data Breach Report. While shorter investigations are pushing down costs globally, reflecting the first decline in five years, IBM found higher regulatory fines, along with detection and escalation costs, are driving up the ultimate recovery price in the United States.

And third-party vendors are the primary attack vector making this worse. 35.5% of breaches in 2024 were linked to third-party access, a 6.5% increase from 2023. The most frequently compromised vendors provided IT services, cloud platforms, and software solutions, with file transfer software vulnerabilities being the most exploited attack vector.

Add data residency laws to the mix: GDPR's penalty ceiling for serious violations runs up to €20 million or 4% of global turnover, and Meta Platforms Ireland Limited was issued a 1.2 billion euro fine following an inquiry into its Facebook service. This fine, which is the largest GDPR fine ever, was imposed for Meta's transfers of personal data to the U.S. You're not Meta-scale, but the legal principle applies to every company that moves EU personal data across borders without adequate safeguards.

Under HIPAA, a vendor becomes a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity — and HHS applies the minimum necessary standard to routine disclosures. So if your integration layer quietly copies sensitive records into another vendor's database, that's not a minor implementation detail. It changes the risk conversation immediately.

Enterprise security teams aren't being paranoid. They're reading the same reports you are, and they're tightening the screws on every vendor in the supply chain — including your integration middleware.

The Hidden Compliance Trap of Traditional Unified APIs

Most unified API platforms solve the integration problem with a sync-and-cache architecture. Here's how it works under the hood: the integration provider polls the source system (like Salesforce or Workday) on a fixed schedule. They pull down the records, transform them into a standardized schema, and store that normalized data in their own database. When your application requests the data, it queries the provider's database — not the actual source system.

This makes reads fast. It also creates a massive compliance problem that most engineering teams don't think about until it's too late.

The moment your integration vendor stores a copy of your customer's employee PII, payroll data, or financial records, three things happen:

1. Your SOC 2 scope expands. That vendor's database is now part of your regulated environment. Your auditors need to evaluate their data-at-rest encryption, access controls, retention policies, and incident response procedures — all systems you don't operate. You must collect their SOC 2 reports, review their access logs, and justify their security posture to your own auditors. Every new cached integration multiplies this administrative overhead.

2. Data residency becomes your problem. If your customer is a European company and the integration vendor stores cached data in a US data center, you've created a cross-border data transfer that falls under GDPR scrutiny. Under GDPR, your cached API vendor becomes a Sub-processor, and you're legally obligated to ensure they comply with the same strict privacy standards you do — suddenly you're navigating the Schrems II ruling and complex Standard Contractual Clauses.

3. You inherit their breach risk. Supply chain compromises intensified in both scale and sophistication in 2025, driven notably by the increasing use of AI by attackers and a strategic pivot toward the digital backbone that connects enterprises. Throughout the year there was a continued surge in third-party and hosted-service compromises across cloud and SaaS ecosystems where attackers leveraged vendor access and multi-tenant architectures to move laterally, harvest credentials and exfiltrate data across downstream customers.

The irony is thick: you adopted a unified API to reduce integration complexity, and it quietly expanded your compliance surface area. The engineering time you saved by not writing the integration gets immediately consumed by months of security questionnaires and legal red tape. This is exactly why the first generation of unified APIs fails at enterprise scale. You need to carefully evaluate the tradeoffs between real-time and cached unified APIs before committing to an architecture.

What Is a Zero-Storage Unified API?

A zero-storage unified API (also called a pass-through API) fundamentally changes the data custody model. Instead of copying data into a centralized database, it acts as a stateless translation layer. It reads live data from the source system, normalizes the response in memory, and returns the standardized payload directly to your application. No database copy. No sync job. No cached dataset sitting on someone else's infrastructure.

Cached unified API — data sits on the provider's servers:

graph LR
    A[Your App] -->|Requests Data| B[Unified API Provider]
    B -->|Queries Local DB| C[(Provider's Database\nStores PII)]
    C -.->|Async Sync\nEvery Hour| D[Third-Party SaaS]
    style C fill:#ffcccc,stroke:#cc0000

That red database? That's your compliance liability. Every record in it needs to be accounted for in your data processing agreements, audit reports, and breach response plans.

Zero-storage unified API — data passes through in memory:

graph LR
    A[Your App] -->|Requests Data| B[Truto Proxy Layer]
    B -->|Real-Time\nHTTP Call| C[Third-Party SaaS]
    C -->|Raw JSON| B
    B -->|JSONata Transform\nIn-Memory| A
    style B fill:#ccffcc,stroke:#00cc00

No database in the middle. Data is transformed in transit and returned directly to your application.

Key characteristics of a true pass-through architecture:

• No Payload Caching: The actual business data (contacts, tickets, employee records) is never written to a persistent database.
• Real-Time Data: Because there is no sync schedule, the data you receive is exactly what exists in the source system at that moment.
• Minimal Attack Surface: If the integration provider is compromised, the attacker gets encrypted OAuth tokens — not millions of rows of your customers' PII.

The technical trick isn't magic. You stop treating each integration as a hand-coded adapter and start treating integrations as configuration. The platform uses declarative mappings — expressed with JSONata, a functional transformation language for JSON — to reshape data in transit. A mapping expression that converts BambooHR's employee format into a unified HRIS schema is just a configuration string. The runtime evaluates it against the incoming response, produces the unified output, and discards the input. No intermediate storage.

A simplified mapping looks like this:

response.{
  id: id,
  name: first_name & ' ' & last_name,
  email: email
}

The point isn't the syntax. The point is that normalization logic lives in data, so the engine can execute it against live payloads in memory instead of first stuffing records into a cache. That's how you normalize 100+ APIs without turning the platform into a zoo of custom handlers or falling into the trap of rigid schemas.

Building a zero-storage API is technically demanding — it's why many legacy providers opted for the easier sync-and-cache route. When you don't store the data, you can't rely on a local database to quickly filter, sort, or paginate records. Instead, the unified API must translate your application's request directly into the specific query language of the target API, whether that's Salesforce's SOQL, HubSpot's filterGroups, or a custom GraphQL query. The platform must also handle rate limiting dynamically — parsing Retry-After headers and managing backoff strategies in real-time while holding the connection open.

Here's what a live unified read looks like from your application's perspective:

const res = await fetch(
  `https://api.truto.one/unified/hris/employees?integrated_account_id=${accountId}&limit=50`,
  { headers: { Authorization: `Bearer ${process.env.TRUTO_API_KEY}` } }
);
 
if (!res.ok) throw new Error(await res.text());
 
const { result, next_cursor } = await res.json();

Behind that one call, Truto fetches the upstream system in real time and maps the response to a unified schema on the fly — instead of serving a vendor-side cached copy.

How Truto's Architecture Solves Data Residency

We built Truto specifically to solve this compliance bottleneck. The entire platform is engineered around the principle of zero integration-specific code and zero payload storage. Security at Truto is an architectural absolute, not an afterthought.

Real-Time Transformation via JSONata

When your application calls Truto's Unified API — say, GET /unified/hris/employees — the request flows through a generic execution engine that:

1. Resolves the integration configuration from the database (base URL, auth scheme, pagination strategy)
2. Transforms the request using declarative JSONata mapping expressions to convert unified query params into the provider's native format
3. Calls the source API live with proper authentication
4. Transforms the response back into the unified schema using the same declarative mapping layer
5. Returns the normalized data directly to your application

Let's trace a concrete example. Suppose your application requests a list of CRM contacts. The request hits Truto's router. The middleware retrieves the encrypted OAuth token, decrypts it in memory, and constructs the outbound HTTP request to Salesforce. Salesforce returns a payload of flat, PascalCase fields. In memory, Truto applies the mapping — a JSONata expression translates FirstName and LastName to a unified name field, converts Salesforce's date formats into ISO 8601 strings, and restructures custom fields. The transformed JSON is immediately streamed back to your application. At no point is the contact data written to a disk, a log file, or a temporary cache.

Credentials Encrypted at Rest with AES-GCM

Truto does store one category of sensitive data: the OAuth tokens and API keys needed to authenticate with your customers' third-party accounts. This is unavoidable — someone has to hold the credentials to make API calls on behalf of connected accounts.

But Truto treats these as high-value secrets. Credential fields — access tokens, refresh tokens, API keys, client secrets — are encrypted at rest using AES-GCM and stored in an integrated_account context object. When connected accounts are listed via the API, sensitive fields are automatically masked. They're only decrypted in memory at the exact moment an outbound HTTP request is constructed.

Token refresh is proactive. Truto doesn't wait for tokens to expire — it schedules renewal 60 to 180 seconds before expiry using Cloudflare's Alarm Durable Objects, with randomized timing to spread load. A mutex lock prevents race conditions when multiple concurrent requests try to refresh the same token. The token is updated and re-encrypted, ensuring your integration never drops a request due to an invalid_grant error — all without ever inspecting or storing the actual business data passing through the connection. If a refresh fails, the account is marked as needs_reauth and a webhook event fires to notify your application. For a deeper look, see our guide to OAuth token refresh architecture.

Ephemeral Spool Nodes for Complex Syncs

Some integrations require fetching massive, paginated datasets — a common bulk extraction problem — like extracting an entire Knowledge Base hierarchy from Notion before sending it to your vector database. For these specific sync jobs, Truto uses spool nodes that temporarily buffer data so it can be combined into a single webhook event.

This is a narrow exception to the zero-storage principle, and it's worth being transparent about:

• Spool node storage is capped at 128KB.
• The data is stored temporarily just long enough to assemble the payload.
• The moment the sync job completes (or fails), the data is aggressively and permanently deleted.

If your compliance team asks "does Truto ever temporarily store data?", the honest answer is: yes, in spool nodes during certain sync operations, with strict size limits and aggressive auto-deletion. It is not a persistent cache of your customers' data.

What This Means for Your Security Review

Here's how Truto's architecture maps to common InfoSec questionnaire concerns:

When Zero-Storage Is Not the Right Choice

Honesty demands we say this: a zero-storage architecture isn't universally better.

A live pass-through inherits upstream latency. If Salesforce takes 4 seconds to respond, your read takes 4 seconds. Cached architectures can serve reads in single-digit milliseconds regardless of the source. If your primary use case is building analytics dashboards over historical integration data, or if you need to run SQL queries across months of synced records, a cached approach may serve you better.

The key distinction is who controls the storage. With Truto's sync jobs, data lands in your data warehouse, under your encryption, subject to your retention policies. That's a fundamentally different compliance posture than having it sit on a middleware vendor's servers.

Turning Compliance into a Competitive Advantage

Here's the strategic play that most engineering teams miss: a zero-storage integration architecture doesn't just remove a blocker from your deals — it actively accelerates them.

When your competitor's integration vendor caches data, their InfoSec review involves weeks of back-and-forth about sub-processor DPAs, data residency guarantees, and breach notification chains. When your integration layer is pass-through, your sales engineers can truthfully say: "Our integration middleware does not store, cache, or replicate your data. Here's the architecture diagram."

That answer collapses what's normally a multi-week security review into a single conversation. For startups selling to enterprise, where supply chain compromise was close behind, costing $4.91 million and taking the longest to resolve at 267 days, CISOs are actively looking for vendors that minimize the blast radius. A pass-through integration layer is exactly that: minimal blast radius by design.

This isn't theoretical. Companies like Sprinto chose Truto specifically because the architecture aligned with their compliance-first positioning. When you're selling security and compliance software, such as GRC platforms, the last thing you need is an integration vendor that creates compliance headaches for your own customers.

Engineering teams should spend their cycles building core product features, not arguing with InfoSec about third-party data residency. By adopting a pass-through unified API, you get the development speed of a normalized schema without the compliance baggage of a cached database.

If you're stuck in a cycle of losing enterprise deals to InfoSec reviews — or if you're proactively building for SOC 2, HIPAA, or GDPR compliance from day one — evaluate your integration architecture through the lens of data storage. Ask your current vendor (or any vendor you're evaluating) three questions:

1. Do you persist any customer payload data? Not credentials — actual customer records.
2. Where does data sit at rest, and under whose encryption keys?
3. If you're breached, what customer data is exposed?

The answers will tell you everything you need to know about your real compliance footprint.