How to Ensure Zero Data Retention When Processing Third-Party API Payloads

Zero Data Retention (ZDR) when processing third-party API payloads means designing an integration architecture that transforms, normalizes, and proxies data entirely in memory, immediately discarding the payload once the HTTP response completes. If you are building B2B software, adopting this architecture is not a theoretical exercise in system design. It is a binary requirement for passing enterprise security audits.

Your enterprise deal just stalled in procurement. The buyer's InfoSec team reviewed your vendor risk assessment and flagged a massive liability: your integration middleware caches their sensitive HRIS records and CRM contacts on shared infrastructure. They classified your integration layer as an unmanaged sub-processor, refused to sign the Business Associate Agreement (BAA), and the deal is effectively dead.

If you process third-party API payloads containing sensitive CRM, HRIS, or financial data, storing that data at rest is a massive liability. Enterprise procurement teams will actively block your deals if your integration architecture relies on caching their regulated data on unverified third-party infrastructure. To pass strict InfoSec reviews and ship integrations fast, you need an architecture that processes data in transit without ever writing it to a database.

This guide breaks down exactly how to architect a Zero Data Retention (ZDR) integration pipeline. We will examine why legacy sync-and-store architectures fail enterprise security audits, how to build a stateless pass-through proxy, and how to use declarative mapping languages to normalize payloads entirely in memory.

The Enterprise Procurement Wall: Why Data at Rest Kills Deals

When you sell B2B SaaS to mid-market and enterprise companies, integration velocity is your primary bottleneck. When you move upmarket, compliance becomes the binary go or no-go for revenue.

Enterprise procurement teams rely on extensive third-party risk management (TPRM) assessments. When your account executive moves a six-figure deal to the final stages, the buyer's procurement team sends over a Standardized Information Gathering (SIG) questionnaire. SIG Core is an extensive assessment with over 850 questions covering 19 to 21 risk categories. It is designed to assess third parties that store or manage highly sensitive or regulated information.

Domain 10 of the SIG questionnaire focuses heavily on Third-Party Risk Management and data at rest. Questions specifically target how sub-processors handle data storage, retention limits, and cryptographic standards for data at rest. If your integration platform stores a copy of the customer's Salesforce or Workday database, you must disclose it.

The global average cost of a data breach reached $4.88 million in 2024, according to IBM's Cost of a Data Breach Report. That same report identified third-party software vulnerabilities and vendor supply chain breaches as major cost amplifiers. Enterprise security teams read these reports. They know that every vendor who caches their data represents a new attack vector. When you introduce a third-party integration platform that syncs and stores their data indefinitely, you are expanding their attack surface and forcing them to audit an entirely new infrastructure stack.

If your architecture relies on data caching, you will spend months arguing with InfoSec teams about encryption standards, SOC 2 boundaries, and data deletion workflows. If your architecture is completely stateless, you bypass these questions entirely.

The Hidden Liability of Sync-and-Cache Architectures

To understand how to build a stateless system, we must first examine why legacy integration platforms default to stateful architectures.

Legacy platforms like Merge.dev and Nango rely heavily on a "sync-and-cache" architecture. In this model, the integration middleware continuously polls the upstream API (like HubSpot or BambooHR), downloads the records, normalizes them, and stores them in a massive multi-tenant database. When your application requests data, it queries the middleware's database, not the actual upstream provider.

Providers build systems this way because it makes certain engineering tasks easier. It allows the middleware to offer fast response times, handle cross-platform filtering, and absorb upstream API rate limits. However, this convenience comes at a catastrophic cost to compliance.

When you use a sync-and-cache platform, customer data is stored indefinitely on infrastructure you do not control. While some platforms are attempting to pivot - Merge.dev recently introduced a specific ZDR toggle for their LLM gateway product - their core unified API products still rely on database persistence. Nango automatically manages data retention in a sync cache, explicitly stating in their documentation that they prune stale payloads after 30 days and perform hard deletions after 60 days of inactivity.

Storing regulated data for 30 to 60 days violates the strict data minimization requirements of SOC 2, HIPAA, and GDPR. Under HIPAA, for example, any entity storing Protected Health Information (PHI) is considered a Business Associate. If your integration tool caches an HRIS payload containing employee medical leave data, that tool is now in scope for HIPAA. You must secure a BAA with them, and your enterprise customer must audit them.

This is why sync-and-cache architectures fail in the enterprise. You are forcing your buyer to accept the security posture of a vendor they did not choose to buy.

What is Zero Data Retention (ZDR) in API Processing?

Zero Data Retention (ZDR) in SaaS integrations means that your integration middleware processes third-party API payloads entirely in memory and never writes customer data to persistent storage.

The payload enters the proxy, gets transformed into a normalized format, gets delivered to your application, and is immediately discarded. There is no cache. There is no database replica. There is no 30-day retention window.

ZDR is becoming a mandatory contractual prerequisite for enterprise deployments processing sensitive data. Major AI providers have established this standard. Anthropic offers specific Zero Data Retention agreements for enterprise customers to guarantee prompts and completions are not stored at rest. Infrastructure providers like API Ninjas market a strict Zero Data Retention Policy where data is processed in milliseconds and discarded immediately, tracking only aggregate usage counts.

When you apply this standard to API integrations, you eliminate the concept of "data at rest" from your middleware layer. You transform your integration pipeline from a data custodian into a transient data processor. This distinction is what allows you to bypass the most difficult sections of the SIG Core questionnaire.

Architecting a Stateless Pass-Through Proxy

To achieve true zero data retention, you must build a stateless pass-through proxy. This architecture requires completely separating your configuration state (which you store) from your execution state (which you discard).

In a ZDR architecture, your database contains zero integration-specific code and zero customer payloads. It only stores the mapping configurations, OAuth tokens, and routing rules required to execute a request.

The Generic Execution Pipeline

When your application requests data from a third-party API, the proxy executes a real-time, in-memory pipeline.

1. Request Ingestion: Your application sends a standard HTTP request to the proxy layer (e.g., GET /unified/crm/contacts).
2. Token Injection: The proxy retrieves the customer's encrypted OAuth token from your secure vault, decrypts it in memory, and attaches it to the outbound request headers.
3. Upstream Execution: The proxy forwards the request directly to the upstream provider (e.g., Salesforce or Workday).
4. In-Memory Transformation: As the upstream provider returns the raw JSON payload, the proxy streams this payload into a declarative mapping engine.
5. Delivery and Destruction: The engine normalizes the data into your unified schema, streams the response back to your application, and allows the memory to be garbage collected. The payload never touches a disk.

Here is how this request flow operates in practice:

sequenceDiagram
    participant Client as Your App
    participant Proxy as Stateless Proxy
    participant Vault as Token Vault
    participant Upstream as Upstream API (Salesforce)
    
    Client->>Proxy: GET /unified/contacts
    Proxy->>Vault: Fetch credentials for connection_id
    Vault-->>Proxy: Encrypted OAuth Token
    Proxy->>Proxy: Decrypt Token (In-Memory)
    Proxy->>Upstream: GET /services/data/v60.0/query<br>Authorization: Bearer [token]
    Upstream-->>Proxy: Raw JSON Payload
    Proxy->>Proxy: Transform via JSONata (In-Memory)
    Proxy-->>Client: Normalized JSON Payload
    Proxy->>Proxy: Drop payload from memory

Declarative Mapping Languages

The technical hurdle in this architecture is transforming complex, deeply nested JSON payloads without writing them to a database for processing. If you try to write custom TypeScript or Python code to map every individual API endpoint, you will introduce memory leaks and stateful variables.

The solution is to use declarative mapping languages like JSONata. JSONata is a lightweight query and transformation language specifically designed for JSON data. By storing JSONata expressions in your database instead of executable code, your proxy can evaluate transformations strictly in memory.

Consider a scenario where you need to normalize a Salesforce Contact record into a standard unified model. You store this JSONata expression in your configuration database:

{
  "id": Id,
  "first_name": FirstName,
  "last_name": LastName,
  "email": Email,
  "phone_numbers": [
    {
      "type": "work",
      "value": Phone
    },
    {
      "type": "mobile",
      "value": MobilePhone
    }
  ],
  "updated_at": LastModifiedDate
}

When the proxy receives the raw Salesforce payload, it applies this exact template against the incoming data stream. The JSONata engine processes the schema translation dynamically. Because the mapping logic is entirely declarative, there is no risk of the proxy accidentally caching the data in a local variable or writing it to a temporary file system.

Handling Edge Cases: Rate Limits and Error Passthrough

Adopting a radical ZDR architecture requires radical honesty about system trade-offs. The most significant trade-off involves how you handle API rate limits.

In a legacy sync-and-cache platform, the middleware absorbs HTTP 429 Too Many Requests errors. If the upstream provider rate limits the connection, the middleware simply queues the request in a database, applies an exponential backoff algorithm, and tries again later.

You cannot do this in a true stateless architecture.

If you queue a request, you are storing state. If you store a payload in a retry queue (like Kafka, RabbitMQ, or a Postgres table) for 15 minutes while waiting for a rate limit window to reset, you have violated Zero Data Retention. You have written the payload to disk.

To maintain ZDR, your proxy must pass the responsibility of rate limit management down to the caller. When an upstream API returns an HTTP 429 error, a stateless proxy passes that error directly back to your application. Your application - which already holds the data and has the right to store it - must handle the retry logic.

Normalizing Rate Limit Headers

While the proxy cannot absorb the 429 error, it can make handling it significantly easier for your engineering team. Every SaaS provider returns rate limit information differently. Shopify uses a leaky bucket algorithm with X-Shopify-Shop-Api-Call-Limit. GitHub uses X-RateLimit-Remaining. Salesforce uses Sforce-Limit-Info.

A top-tier stateless proxy normalizes these disparate upstream headers into standardized IETF rate limit headers before returning the response to the client. The IETF standard defines three core headers:

• ratelimit-limit: The total request quota for the current window.
• ratelimit-remaining: The number of requests remaining in the current window.
• ratelimit-reset: The time at which the rate limit window resets (usually represented as a Unix timestamp or seconds remaining).

When your proxy processes a request, it extracts the provider-specific rate limit data in memory and injects the standardized IETF headers into the outbound response.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
ratelimit-limit: 100
ratelimit-remaining: 0
ratelimit-reset: 1715432100
 
{
  "error": "rate_limit_exceeded",
  "message": "Upstream provider rate limit exceeded."
}

This approach gives your application the exact telemetry it needs to calculate an accurate backoff delay, without requiring the proxy to store the payload in a persistent queue.

Passing InfoSec: Proving Zero Data Retention to Auditors

Building a ZDR architecture is only half the battle. The other half is proving it to enterprise procurement teams so you can unblock your deals.

When you face a SIG Core questionnaire or a custom TPRM assessment, you need to provide explicit, highly technical documentation that proves your integration middleware acts as a transient processor. You must distance your architecture from legacy sync-and-cache models.

Here is how you should document your pass-through architecture in security whitepapers and vendor questionnaires:

1. Define the Data Lifecycle Explicitly State exactly when data enters memory and when it is destroyed. Use language like: "Our integration architecture utilizes a strict pass-through proxy. Third-party API payloads are processed entirely in memory for schema normalization and are immediately discarded upon HTTP response completion. We do not utilize database caching, message queues, or persistent storage for customer payloads."

2. Clarify the Sub-Processor Boundary Enterprise InfoSec teams are hunting for unmanaged sub-processors. If you use a third-party unified API that adheres to ZDR, you must document their exact role. "Our unified API provider acts solely as a stateless routing and transformation layer. Because they do not write customer data to persistent storage, they are classified as a transient network processor, heavily reducing the compliance scope regarding data at rest."

3. Detail the Logging Policy Auditors will check your application logs. If you achieve ZDR in your database but accidentally log full JSON payloads to Datadog or CloudWatch, you have failed the audit. Explicitly state your logging policies: "Our proxy architecture strictly prohibits logging request or response body payloads. Telemetry is restricted to HTTP status codes, latency metrics, and standardized IETF rate limit headers."

4. Address Rate Limits and Queuing Pre-empt the auditor's concerns about retry mechanisms. "To ensure zero data retention, our proxy does not queue or retry failed requests. Upstream rate limit errors (HTTP 429) are passed directly to the client application, ensuring that payloads are never temporarily written to disk in a retry queue."

By providing these exact architectural guarantees, you give the InfoSec team the evidence they need to check their boxes and approve the deal. You transform integration compliance from a massive liability into a demonstrated engineering strength.

Technical Appendix: How Pass-Through Normalization Is Implemented

This appendix goes one level deeper into the mechanics of a pass-through unified API. It answers the question engineering leaders keep asking during vendor evaluations: how do unified API platforms handle real-time data without caching customer information?

Overview: Pass-Through Guarantees

A pass-through unified API gives you real-time data by treating every request as a live call to the upstream provider, not a lookup against a local mirror. There is no polling job, no nightly sync, no reconciliation window. When your application asks for a Salesforce contact, the proxy asks Salesforce for that contact in that moment, transforms the response in memory, and returns it. This is what makes real-time data consistency straightforward: the source of truth is always the provider, so the payload your application receives reflects the provider's state at the exact millisecond of the request. Consistency is not a caching problem you have to solve - it is a property you inherit by never caching.

The guarantees that make ZDR work are:

• Freshness: every response reflects the upstream provider's current state at request time
• Statelessness: the proxy holds no cross-request memory of customer payloads
• Bounded lifetime: payload lifetime is scoped to a single HTTP request handler
• Deterministic destruction: memory is released as soon as the response is flushed to the caller
• No shadow copies: no derived indexes, denormalized tables, or search caches are built from the payload

In-Memory Normalization Lifecycle (buffers, TTL, GC)

The lifecycle of a payload inside a pass-through proxy is short and mechanical. From ingress to garbage collection, it moves through five stages:

1. Ingress buffer: the upstream provider's response is read into an in-memory buffer scoped to the request handler.
2. Parse: the buffer is parsed into a language-level object and handed to the mapping engine.
3. Transform: a JSONata expression is compiled once and evaluated against the parsed object. The evaluator produces a new object matching the unified schema.
4. Serialize and flush: the transformed object is serialized to JSON and written to the outgoing response stream.
5. Release: once the response stream closes, all references to the parsed object, the transformed object, and the raw buffer go out of scope. The garbage collector reclaims the memory on its next cycle.

There is no explicit TTL configuration because there is no persistent buffer to expire. The effective TTL for any payload is the duration of a single HTTP request - typically well under two seconds for a normalized list call. Related-resource fan-out extends this window slightly, since each sub-fetch is a nested in-memory operation that joins back onto the parent record before the response is flushed. Even in the fan-out case, every intermediate array lives inside the request handler's local scope and dies with it.

Streaming responses (large exports, bulk syncs) work the same way at chunk granularity: each chunk is transformed and forwarded, and the previous chunk's memory is released before the next one arrives. The high-water mark for payload memory is one chunk, not the full dataset. This is what lets a pass-through proxy handle multi-gigabyte exports without any disk footprint.

Transient Logging and Crash Safety

Logging is the most common way well-intentioned ZDR architectures accidentally leak data. The correct policy is to log HTTP status codes, request IDs, integration names, latency, and error class - never the request or response body. Payload bytes must be treated the same as PHI: they never reach a log sink, an APM tool, or a stack-trace attachment.

The crash-safety story matters just as much. If a proxy process dies mid-request, three things must be true:

• No swap-to-disk: swap should be disabled on the runtime hosts, so memory pages containing decrypted payloads cannot spill to disk under pressure.
• No core dumps: core dump generation should be disabled at the OS level, since a core dump would capture live payload buffers.
• No error-object payload capture: exception handlers should never attach the raw request or response body to the error object. The stack trace and error message are sufficient to diagnose failures without carrying customer data into an error reporting pipeline.

The consequence is intentional: when a request fails mid-flight, the payload is unrecoverable. There is no retry queue holding a copy. The client sees an error, retries at the application layer if the operation is idempotent, and the failed payload is gone. This is the correct behavior for ZDR - a system that could recover a mid-flight payload is a system that persisted it.

Exactly What We Persist: Credentials, Tokens, and Metadata

ZDR does not mean "store nothing." It means "store nothing about customer records." A pass-through proxy still needs a small amount of durable state to route requests and authenticate them. The persisted surface should be limited to:

Nothing in that list is a customer record. No contact names, no employee salaries, no support ticket bodies, no invoice line items. If a full database dump of the proxy leaked tomorrow, an attacker would learn which integrations your customers use and would obtain a set of encrypted OAuth tokens. They would not learn the contents of a single CRM record, HRIS payroll run, or ticketing conversation.

This is the practical difference between a data custodian and a transient processor. A custodian's blast radius is the entire history of customer records. A transient processor's blast radius is the credentials themselves, which can be rotated in minutes.

Encryption & Token Rotation Policies

The credentials and secrets that do get persisted are the highest-value targets in the entire architecture. They must be protected with the same rigor an authoritative provider would apply to their own credential store.

Encryption at rest. Every OAuth token, API key, webhook signing secret, and customer-supplied credential is encrypted before being written. Encryption uses AES-256 (or an equivalent authenticated encryption scheme) with keys held in a dedicated key management service, not alongside the ciphertext. Database backups inherit the same encryption. A dump of the database yields ciphertext only.

Encryption in transit. All upstream calls use TLS 1.2 or higher. The proxy refuses to negotiate weaker cipher suites, and certificate pinning is applied for providers that expose stable roots.

Token rotation. Access tokens expire on the schedule set by the upstream provider - typically 30 to 60 minutes. Two mechanisms keep them fresh:

• Proactive refresh: the platform schedules a refresh shortly before the access token's expiry. The scheduled work exchanges the refresh token for a new access token, writes the updated ciphertext back to the account record, and rearms itself for the next expiry.
• On-demand refresh: if a request arrives with an expired token (clock skew, missed schedule, long-running operation), the token is refreshed inline before the outbound call is made.

Both paths converge on the same refresh routine, protected by a per-account mutex so concurrent callers cannot double-refresh and invalidate each other's tokens. Concurrent callers await the in-progress refresh instead of racing.

Credential access logging. Every read of an encrypted credential is written to an audit log with the calling service, the account ID, the request ID, and the timestamp. Payload bodies are still excluded from these logs; only the fact of a credential fetch is recorded. This gives auditors a complete picture of which system read which token, when, and why, without reintroducing payload retention through the back door.

Rotation on compromise. If a token is suspected to be compromised, the account can be force-refreshed or the refresh token revoked upstream. The mutex ensures the rotation completes cleanly before the next outbound call executes.

How to Verify Zero Data Retention (audit artifacts)

Claims of ZDR are only useful if you can prove them. When an enterprise InfoSec team asks for evidence, these are the artifacts that actually move the review forward:

1. Data flow diagram: a signed diagram showing every hop between the customer's provider and your application, with each hop labeled "in-memory only" or "persistent" and the retention window noted for anything persistent.
2. Schema inventory: a list of every database table and every field, annotated to show that no field holds a raw upstream payload. Auditors should be able to grep the schema for anything that looks like body, payload, response, or record_data and find nothing.
3. Log sink inventory: a list of every log destination (APM, SIEM, error tracker) with the exact fields that are and are not forwarded. Bodies must be on the "not forwarded" list, and the redaction rules must be enforced at the emit layer, not at the sink.
4. Runtime configuration: evidence that swap is disabled, core dumps are disabled, and error handlers do not attach payloads. A snippet from the production host configuration is usually enough.
5. Third-party sub-processor list: the vendors that touch the request path (hosting, DNS, TLS termination), each with their own ZDR posture documented. Enterprise reviewers want to see that the chain does not silently reintroduce retention downstream.
6. Penetration test and SOC 2 reports: independent attestations that the controls above are actually in place. SOC 2 Type II is the standard bar; a Type I report is a red flag because it only tests design, not operation.
7. Traffic capture on demand: if the auditor requests it, a captured request/response pair showing the payload entering memory, being transformed, and being flushed - with a corresponding memory profile showing the buffer released.

The single most persuasive artifact is a live demonstration. Point the auditor at a test connection, issue a request, and walk through the process listing, the database queries, and the log entries in real time. They should see the request in the access log, the credential fetch in the audit log, and nothing in the database or in log body fields. If your architecture is real, this demo takes about ten minutes and closes the section.

Strategic Next Steps for Engineering Leaders

Enterprise security requirements are not going to soften. As organizations become hyper-aware of third-party risk and supply chain vulnerabilities, sync-and-cache integration architectures will become increasingly impossible to sell into the enterprise.

If you are currently relying on middleware that stores customer data for 30 days, you are sitting on a compliance time bomb. Every deal you move into procurement risks being derailed by a single SIG Core questionnaire.

Transitioning to a stateless pass-through proxy architecture requires a shift in how you handle state, rate limits, and error recovery. Your application must take responsibility for backoff logic, and you must rely on declarative mapping to handle transformations in memory. The engineering effort required to make this shift is significant, but the alternative is watching six-figure enterprise deals die in procurement.

Take a hard look at your current integration pipeline. Trace the exact path a third-party payload takes from the provider to your application. If it touches a disk, a database, or a persistent queue at any point in that journey, you do not have Zero Data Retention.